digitalmars.D.bugs - [Issue 3092] New: Indexing a tuple produces a tuple containing the indexed element
- d-bugmail puremagic.com (32/32) Jun 25 2009 http://d.puremagic.com/issues/show_bug.cgi?id=3092
- d-bugmail puremagic.com (21/21) Jun 25 2009 http://d.puremagic.com/issues/show_bug.cgi?id=3092
- d-bugmail puremagic.com (13/13) Jun 25 2009 http://d.puremagic.com/issues/show_bug.cgi?id=3092
- d-bugmail puremagic.com (12/15) Jun 25 2009 http://d.puremagic.com/issues/show_bug.cgi?id=3092
- d-bugmail puremagic.com (93/93) Oct 09 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3092
- d-bugmail puremagic.com (54/54) Oct 10 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3092
- d-bugmail puremagic.com (8/8) Oct 11 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3092
- d-bugmail puremagic.com (10/10) Oct 11 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3092
- d-bugmail puremagic.com (17/17) Oct 11 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3092
- d-bugmail puremagic.com (13/27) Oct 19 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3092
- d-bugmail puremagic.com (12/12) Oct 19 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3092
- d-bugmail puremagic.com (9/13) Oct 20 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3092
- d-bugmail puremagic.com (10/19) Oct 20 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3092
- d-bugmail puremagic.com (13/27) Oct 20 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3092
- d-bugmail puremagic.com (12/12) Dec 17 2011 http://d.puremagic.com/issues/show_bug.cgi?id=3092
- d-bugmail puremagic.com (13/13) Dec 18 2011 http://d.puremagic.com/issues/show_bug.cgi?id=3092
- d-bugmail puremagic.com (6/6) Feb 20 2012 http://d.puremagic.com/issues/show_bug.cgi?id=3092
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
http://d.puremagic.com/issues/show_bug.cgi?id=3092 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
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 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
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 2009-06-25 11:46:03 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.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
http://d.puremagic.com/issues/show_bug.cgi?id=3092 Manuel König <manuelk89 gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |manuelk89 gmx.net 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
http://d.puremagic.com/issues/show_bug.cgi?id=3092 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
http://d.puremagic.com/issues/show_bug.cgi?id=3092 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
http://d.puremagic.com/issues/show_bug.cgi?id=3092 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
http://d.puremagic.com/issues/show_bug.cgi?id=3092 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
http://d.puremagic.com/issues/show_bug.cgi?id=3092 Don <clugdbug yahoo.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |clugdbug yahoo.com.auI 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
http://d.puremagic.com/issues/show_bug.cgi?id=3092 Leandro Lucarella <llucax gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- patch| | 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
http://d.puremagic.com/issues/show_bug.cgi?id=3092 ---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
http://d.puremagic.com/issues/show_bug.cgi?id=3092Thanks! 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: -------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 :)
Oct 20 2010
http://d.puremagic.com/issues/show_bug.cgi?id=3092 Leandro Lucarella <llucax gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |llucax gmail.com 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.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
http://d.puremagic.com/issues/show_bug.cgi?id=3092 Kenji Hara <k.hara.pg gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Platform|Other |All Version|1.045 |D1 & D2 OS/Version|Windows |All --- https://github.com/D-Programming-Language/dmd/pull/567 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Dec 17 2011
http://d.puremagic.com/issues/show_bug.cgi?id=3092 Walter Bright <bugzilla digitalmars.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |bugzilla digitalmars.com Resolution| |FIXED 23:23:48 PST --- https://github.com/D-Programming-Language/dmd/commit/31b955584130b890dac7786b500c31c75e19e4d8 https://github.com/D-Programming-Language/dmd/commit/fcd345d18de57faf49f972f5a6d74e0b4e2d2b4e -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Dec 18 2011
http://d.puremagic.com/issues/show_bug.cgi?id=3092 *** Issue 2422 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 20 2012