[Issue 3092] Indexing a tuple produces a tuple containing the indexed element
https://issues.dlang.org/show_bug.cgi?id=3092 Andrei Alexandrescu changed: What|Removed |Added Version|D1 & D2 |D2 --
[Issue 3092] Indexing a tuple produces a tuple containing the indexed element
http://d.puremagic.com/issues/show_bug.cgi?id=3092 --- Comment #16 from yebblies 2012-02-20 19:05:32 EST --- *** 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: ---
[Issue 3092] Indexing a tuple produces a tuple containing the indexed element
http://d.puremagic.com/issues/show_bug.cgi?id=3092 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #15 from Walter Bright 2011-12-18 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: ---
[Issue 3092] Indexing a tuple produces a tuple containing the indexed element
http://d.puremagic.com/issues/show_bug.cgi?id=3092 Kenji Hara changed: What|Removed |Added Platform|Other |All Version|1.045 |D1 & D2 OS/Version|Windows |All --- Comment #14 from Kenji Hara 2011-12-17 22:49:26 PST --- 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: ---
[Issue 3092] Indexing a tuple produces a tuple containing the indexed element
http://d.puremagic.com/issues/show_bug.cgi?id=3092 Leandro Lucarella changed: What|Removed |Added CC||llu...@gmail.com --- Comment #13 from Leandro Lucarella 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: ---
[Issue 3092] Indexing a tuple produces a tuple containing the indexed element
http://d.puremagic.com/issues/show_bug.cgi?id=3092 --- Comment #12 from Don 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: ---
[Issue 3092] Indexing a tuple produces a tuple containing the indexed element
http://d.puremagic.com/issues/show_bug.cgi?id=3092 --- Comment #11 from Manuel K�nig 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: ---
[Issue 3092] Indexing a tuple produces a tuple containing the indexed element
http://d.puremagic.com/issues/show_bug.cgi?id=3092 Leandro Lucarella changed: What|Removed |Added Attachment #783 is|1 |0 patch|| --- Comment #10 from Leandro Lucarella 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: ---
[Issue 3092] Indexing a tuple produces a tuple containing the indexed element
http://d.puremagic.com/issues/show_bug.cgi?id=3092 Don changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #9 from Don 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: ---
[Issue 3092] Indexing a tuple produces a tuple containing the indexed element
http://d.puremagic.com/issues/show_bug.cgi?id=3092 --- Comment #8 from Manuel K�nig 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: ---
[Issue 3092] Indexing a tuple produces a tuple containing the indexed element
http://d.puremagic.com/issues/show_bug.cgi?id=3092 --- Comment #7 from Manuel K�nig 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: ---
[Issue 3092] Indexing a tuple produces a tuple containing the indexed element
http://d.puremagic.com/issues/show_bug.cgi?id=3092 --- Comment #6 from Manuel K�nig 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: ---
[Issue 3092] Indexing a tuple produces a tuple containing the indexed element
http://d.puremagic.com/issues/show_bug.cgi?id=3092
--- Comment #5 from Manuel K�nig 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: ---
[Issue 3092] Indexing a tuple produces a tuple containing the indexed element
http://d.puremagic.com/issues/show_bug.cgi?id=3092
Manuel K�nig changed:
What|Removed |Added
CC||manuel...@gmx.net
--- Comment #4 from Manuel K�nig 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: ---
[Issue 3092] Indexing a tuple produces a tuple containing the indexed element
http://d.puremagic.com/issues/show_bug.cgi?id=3092 Jarrett Billingsley changed: What|Removed |Added CC||jarrett.billings...@gmail.c ||om --- Comment #3 from Jarrett Billingsley 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: ---
[Issue 3092] Indexing a tuple produces a tuple containing the indexed element
http://d.puremagic.com/issues/show_bug.cgi?id=3092 Stewart Gordon changed: What|Removed |Added Keywords||wrong-code CC||s...@iname.com --- Comment #2 from Stewart Gordon 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: ---
[Issue 3092] Indexing a tuple produces a tuple containing the indexed element
http://d.puremagic.com/issues/show_bug.cgi?id=3092
--- Comment #1 from Max Samukha 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: ---
