www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 3092] New: Indexing a tuple produces a tuple containing the indexed element

reply d-bugmail puremagic.com writes:
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: -------
Jun 25 2009
next sibling parent d-bugmail puremagic.com writes:
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: -------
Jun 25 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Jun 25 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Jun 25 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Oct 09 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Oct 10 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Oct 11 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Oct 11 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Oct 11 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Oct 19 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3092


Leandro Lucarella <llucax gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #783 is|1                           |0
              patch|                            |


--- Comment #10 from Leandro Lucarella <llucax gmail.com> 2010-10-19 15:06:05
PDT ---
(From update of attachment 783)
Remove patch type to the attached dstress test as it isn't in patch format

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 19 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3092



--- Comment #11 from Manuel König <manuelk89 gmx.net> 2010-10-20 03:48:35 PDT
---
(In reply to comment #9)
 
 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.

Sure, see here: http://drop.io/dstres_results_rev714 It contains the dstress results for dmd rev714 and my patched version. I can also test the most recent dmd version later, but my homework comes first :) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 20 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3092



--- Comment #12 from Don <clugdbug yahoo.com.au> 2010-10-20 07:20:29 PDT ---
(In reply to comment #11)
 (In reply to comment #9)
 
 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.

Sure, see here: http://drop.io/dstres_results_rev714 It contains the dstress results for dmd rev714 and my patched version. I can also test the most recent dmd version later, but my homework comes first :)

Thanks! That's exactly what I was after. There has been 1 regression since I last saw dstress results (for DMD1.051). I've created bug 5086. Don't bother redoing it with the latest DMD, there won't be any changes. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 20 2010
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3092


Leandro Lucarella <llucax gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |llucax gmail.com


--- Comment #13 from Leandro Lucarella <llucax gmail.com> 2010-10-20 15:55:13
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.

Added to dstress, changeset 1622: http://www.dsource.org/projects/dstress/changeset/1622%3Ad402aa53926c Thanks! -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 20 2010