Entire project, run make; should fail with same assertion as before.
application/octet-stream
200578
Comments
Comment #0 by b.helyer — 2009-09-20T21:16:10Z
File is attached. You don't need to be able to link (and won't be able to), but compiling it with `dmd main.d -c -g` causes an assertion failure:
$ dmd main.d -c -g
dmd: glue.c:958: virtual unsigned int Type::totym(): Assertion `0' failed.
Aborted
However, using `-gc` works fine:
$ dmd main.d -c -gc
$
Comment #1 by b.helyer — 2009-09-20T21:17:45Z
Created attachment 462
Source file that causes compiler to crash.
Main entry to my roguelike; the context is not important.
Comment #2 by clugdbug — 2009-09-22T06:16:01Z
This cannot be compiled. It imports a whole bunch of files which are not attached.
Please provide a complete test case.
Comment #3 by b.helyer — 2009-09-22T06:38:05Z
Oops, sorry I didn't think that through.
Okay, rolling back to the commit that triggered the bug... and it's no longer triggered (and it was reliably when I submitted it). Nevermind, 'cannot reproduce' I guess. Bizarre.
Comment #4 by clugdbug — 2009-09-22T07:06:43Z
If it's like the other ICE(glue.c) bug which is currently open, it might be compile-order dependent. Otherwise, please close as invalid.
Comment #5 by b.helyer — 2009-09-22T07:17:50Z
Jimmied around a bit; no luck. If it comes up again I'll pay closer attention.
Comment #6 by b.helyer — 2009-09-22T08:43:46Z
Created attachment 463
Entire project, run make; should fail with same assertion as before.
I figured it out; I had uncommited changes which I had reverted to post the project -- once I re-added them, the problem came back. In level.d:
alias TypeTuple!(int, int) Coordinate;
...
Creature[Coordinate] mCreatureMap; // <-- Remove this line and the compiler doesn't crash.
Comment #7 by clugdbug — 2009-09-23T00:38:42Z
I reduced that 1MB test case down to 3 lines <g>:
template Tuple(T...){
alias T Tuple;
}
int[ Tuple!(int) ] foo;
---------
Segfaults on D1, as well; also happens on Windows as well as Linux.
Curiously, this didn't segfault on 1.010 and earlier, but segfaults on 1.020. But I believe it was bad code generation on those early compilers, so not a regression.
Comment #8 by clugdbug — 2009-09-23T00:39:21Z
Comment on attachment 463
Entire project, run make; should fail with same assertion as before.
This attachment is now obsolete.
Comment #9 by clugdbug — 2009-09-23T05:52:50Z
This is ice-on-invalid: the key of an AA must be a type. Although the declaration is accepted when the -g flag isn't used, that's also a bug. It's pretty meaningless -- there's no way to put anything into the AA! The declaration should be rejected.
Comment #10 by clugdbug — 2009-09-24T00:45:31Z
PATCH: This is very easy. Just disallow tuples as AA keys.
In mtype.c, in Type *TypeAArray::semantic(Loc loc, Scope *sc), at line 3293:
switch (index->toBasetype()->ty)
{
case Tbool:
case Tfunction:
case Tvoid:
case Tnone:
+ case Ttuple:
error(loc, "can't have associative array key of %s", index->toBasetype()->toChars());
break;
}
And here's a test case for the test suite. Should compile without error.
---
template Tuple(T...){
alias T Tuple;
}
// Bugzilla 3336
static assert(!is(int[ Tuple!(int, int) ]));