http://d.puremagic.com/issues/show_bug.cgi?id=3092

           Summary: Indexing a tuple produces a tuple containing the
                    indexed element
           Product: D
           Version: 1.045
          Platform: Other
        OS/Version: Windows
            Status: NEW
          Severity: major
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: samukha@voliacable.com


template Foo(A...)
{
    alias A[0] Foo;
}

void foo()
{
}

static assert(is(Foo!(int, foo) == int));

void main()
{
}

Error: static assert  (is((int) == int)) is false
----

This one was slightly annoying as it came along with http://d.puremagic.com/issues/show_bug.cgi?id=2229, which gets in the way regularly and which is almost a year old now.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3092





--- Comment #1 from Max Samukha <samukha@voliacable.com>  2009-06-25 02:02:47 PDT ---
A workaround (which doesn't mean that the bug is not critical):

template StaticTuple(A...)
{
    alias A StaticTuple;
}

template Foo(A...)
{
    alias StaticTuple!(A[0])[0] Foo;
}

void foo()
{
}

static assert(is(Foo!(int, foo) == int));

void main()
{
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3092


Stewart Gordon <smjg@iname.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
                 CC|                            |smjg@iname.com




--- Comment #2 from Stewart Gordon <smjg@iname.com>  2009-06-25 11:33:25 PDT ---
Where it's got (int) as a distinct type from, I don't get either.  It's always been my understanding that a 1-element tuple and its element are one and the same.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3092


Jarrett Billingsley <jarrett.billingsley@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jarrett.billingsley@gmail.c
                   |                            |om




--- Comment #3 from Jarrett Billingsley <jarrett.billingsley@gmail.com>  2009-06-25 11:46:03 PDT ---
(In reply to comment #2)
> Where it's got (int) as a distinct type from, I don't get either.  It's always been my understanding that a 1-element tuple and its element are one and the same.

I don't think that has ever been the case..

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3092


Manuel König <manuelk89@gmx.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manuelk89@gmx.net


--- Comment #4 from Manuel König <manuelk89@gmx.net> 2010-10-09 12:33:07 PDT ---
I just rediscovered this bug and reported it on the ldc bugtracker first, see http://www.dsource.org/projects/ldc/ticket/435 . It's a frontend bug, and only happens when you pass more than one argument to the template. I will copy my findings here (using ldc to compile, but the result is the same with dmd v2.049 and v1.056).

There are various bugs with the "..." syntax for creating tuples, but I think they all root back to types being errously converted to singletons of itself when the number of arguments is >= 2.

// file tup_bug.d
template TupleBug(values...)
{
    alias values[0] v0;
    alias values[0][0][0][0][0] chain;

    pragma(msg, "values:    ", values);
    pragma(msg, "v0:        ", v0);
    pragma(msg, "values[0]: ", values[0]);
    pragma(msg, "chain:     ", chain);
}

pragma(msg, "-- TupleBug!(int):");
alias TupleBug!(int) _;

pragma(msg, "\n-- TupleBug!(int, \"foo\"):");
alias TupleBug!(int, "foo") _0;

void main() {}

Output of ldc 0.9.2 is

$ldc tup_bug.d
-- TupleBug!(int):
values:    (int)
v0:        int
values[0]: int
chain:     int[0LU][0LU][0LU][0LU]

-- TupleBug!(int, "foo"):
values:    tuple((int),"foo")
v0:        (int)
values[0]: int
chain:     (int)

Expected output for TupleBug?!(int, "foo"):

values:    tuple(int,"foo")
v0:        int
values[0]: int
chain:     int[0LU][0LU][0LU][0LU]

The output for TupleBug?!(int) is ok, but when the number of parameters is 2 or greater, then all types T in the parameter list are implicitly converted to a singleton tuple (T), as can be seen here in case of T=int. Even worse, you can not index the singleton tuple, it just returns a copy of itself, which is evident when looking at the output of chain.

In TupleBug?!(int), chain is a multidimensional array, which is correct. But in
TupleBug?!(int, "foo"), the output of chain is just (int).

I also think the usage of tuple(...) and (...) in the output is inconsistend,
it seems like tuple(...) is used for tuples of length >= 2 and (...) is used
for singleton tuples only. I would use tuple(...) in both cases.

============================================================================

One really annoying consequence that's bugging me is that assigning names to template parameters via aliasing is not possible:

// file tup_bug_consequence.d
struct TypeAndName(args...)
{
    alias args[0] type; // "..." bug => type = (args[0]), not args[0]
    const char[] name = args[1];
}

template DeclVar(data)
{
    mixin("data.type "~data.name~";");
}

void main()
{
    mixin DeclVar!(TypeAndName!(int, "foo"));

    pragma(msg, "foo:          ", foo);
    pragma(msg, "typeof(foo): ", typeof(foo));
    foo = 3;
}

I expect this to define "int foo;" inside main, but due to the "..." bug described above, that doesn't work:

$ldc tup_bug_consequence.d
foo        : tuple(_foo_field_0)
typeof(foo): (int)
tup_bug_consequence.d(18): Error: foo is not an lvalue
tup_bug_consequence.d(18): Error: cannot implicitly convert expression (3) of
type int to (int)
tup_bug_consequence.d(18): Error: cannot cast int to (int)

This TypeAndName? construct is really useful for parsing template arguments of the form (Type1, "name1", ..., TypeN, "nameN"), but as soon as you try to get an alias to one of the types, everything breaks. A workaround is to always work with the parameter tuple directly and don't alias its items, but then all your templates are reduced to magic tuple indexing code that no one can understand.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3092



--- Comment #5 from Manuel König <manuelk89@gmx.net> 2010-10-10 06:55:54 PDT ---
Some updates:

template TupleBug(values...)
{
    pragma(msg, "values: ", values);
}

alias TupleBug!(int, int) _0; // prints 'values: (int, int)'
alias TupleBug!(int, 1)   _1; // prints 'values: tuple((int), 1)'

After investigating the frontend, i can explain this behaviour:

(int, int) is treated as a type by dmd, not as a tuple, but the mixed tuple
(int, 1) is treated as a tuple. To see that, go to DsymbolExp::semantic in
expression.c and insert the printf's like this:

    t = s->getType();
    if (t)
    {
        // entered for TupleBug!(int, int)
        printf("'%s' is type\n", t->toChars()); // prints "'(int, int)' is
type"
        return new TypeExp(loc, t);
    }

    TupleDeclaration *tup = s->isTupleDeclaration();
    if (tup)
    {
        // entered for TupleBug!(int, 1)
        printf("'%s' is tuple\n", tup->toChars()); // prints "'values' is
tuple"
        e = new TupleExp(loc, tup);
        printf("e = %s\n", e->toChars()); // prints 'e = tuple((int), 1)'
        e = e->semantic(sc);
        printf("e->semantic(sc) = %s\n", e->toChars()); // prints 'e->semantic
= tuple((int), 1)
        return e;
    }

I don't know if it's intended behaviour to treat type tuples separately from mixed tuples even in the frontend, but that's how it is. Type tuples don't seem to be buggy (they are not affected by any aliasing, indexing or pragma(msg,...) bugs described before). So what's really buggy are the 'true' mixed tuples.

I can at least explain what causes the pragma(msg, values) bug, which currently
prints tuple((int), 1). The bug is not, as it seems, that (int) is a singleton
tuple containing an int, it's actually a bug in e->toChars(), which calls
TupleExp::toCBuffer [that prints the 'tuple(' ')' frame], which calls
argsToCBuffer, which treats every argument as an expression, but it shouldn't
do that, the arguments are (int, 1), and 'int' is not an expression. When
argsToCBuffer calls expToCBuffer on the int 'expression', it thinks the
expression has an operator precedence lower than PREC_assign, so it put's the
parantheses around the expr and produces '(int)'.

A workaround is to do 'e->op = TOK_assign' in TupleExp::TupleExp when pushing a type to the tuple exps, but that's only a hack.

I will try to find a proper fix and also investigate into the other bugs that mixed tuples have.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3092



--- Comment #6 from Manuel König <manuelk89@gmx.net> 2010-10-11 08:12:47 PDT ---
Created an attachment (id=782)
Patch for this bug created with "svn diff mtype.c", apply in the frontend
directory

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3092



--- Comment #7 from Manuel König <manuelk89@gmx.net> 2010-10-11 08:17:19 PDT ---
Created an attachment (id=783)
Testcase for dstress, add to dstress/compile/t

I'm not sure about the numbering scheme in dstress, I just used the next free available number (27) for my testcase. Marked as patch, although it's for dstress and not dmd.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3092



--- Comment #8 from Manuel König <manuelk89@gmx.net> 2010-10-11 08:17:55 PDT ---
I have now fixed the bug, it's a trivial 7 line patch which teaches TypeSArray::resolve(...) to recognize if it's indexing a type element. Without the patch, TypeSArray::resolve(...) will create a 1-element-slice when indexing a type in a tuple. This fixes the bug described in this issue.

This patch does not fix the pragma(msg, "values:    ", values); bugs, which is caused by another bug I described in a previous comment. That one would also be easy to fix, it's only a formatting bug, I'm just not sure how a proper patch for that would look like.

I also tested dmd rev 714 (that one in branch dmd1.x) and my patched version of it in dstress. No improvements, regressions or changes were introduced. I then created a testcase that can be added to the dstress/compile/t directory, which passes with my patch applied, but fails in dmd rev 714.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3092


Don <clugdbug@yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |clugdbug@yahoo.com.au


--- Comment #9 from Don <clugdbug@yahoo.com.au> 2010-10-19 13:32:36 PDT ---
(In reply to comment #8)
> I have now fixed the bug, it's a trivial 7 line patch which teaches TypeSArray::resolve(...) to recognize if it's indexing a type element. Without the patch, TypeSArray::resolve(...) will create a 1-element-slice when indexing a type in a tuple. This fixes the bug described in this issue.
> 
> This patch does not fix the pragma(msg, "values:    ", values); bugs, which is caused by another bug I described in a previous comment. That one would also be easy to fix, it's only a formatting bug, I'm just not sure how a proper patch for that would look like.
> 
> I also tested dmd rev 714 (that one in branch dmd1.x) and my patched version of it in dstress. No improvements, regressions or changes were introduced. I then created a testcase that can be added to the dstress/compile/t directory, which passes with my patch applied, but fails in dmd rev 714.

Sounds as though you have been running dstress. Could you please post the results somewhere? I would be very interested to see how many dstress bugs are still unfixed in the most recent DMD version.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------