Summary: ICE(mtype.c) function pointer type deduction puts
                    compiler in corrupt state
           Product: D
           Version: 2.029
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Keywords: ice-on-valid-code
          Severity: critical
          Priority: P2
         Component: DMD

This is the ICE case originally reported as a comment in bug 2672.

auto x = &bar;
int bar() { return 1;}
int function() y = null;
Assertion failure: 'tn->mod == MODinvariant' on line 760 in file 'mtype.c'

This one is really tough. What's happening is that when a forward reference is
involved, auto type deduction for function pointers is failing to initialize
something about the Type object (or maybe the TypeNext object) for that
function pointer type. [ At the very least, the 'mod' member of the Type is
wrong, but it could be more serious than that, it might even affect D1].
Then, when the NEXT declaration of a function pointer of exactly the same type
occurs, it grabs the corrupted Type object. This has the wrong const/immutable
state, so an ICE occurs.

This is particularly nasty, because adding a declaration of that exact same
function pointer type earlier in the file (or maybe even in another module?)
will prevent the ICE, since it will have created a valid Type object before the
auto declaration gets a chance to make a corrupt one.
So, for example
int function() z = null;
auto x = &bar;
int bar() { return 1;}
int function() y = null; // Test case 1

does not ICE, but change the declaration of z to be 'uint function()', and it
will crash at the declaration of y, even though it's the declaration at x which
is the root cause. Marking as critical since it can be incredibly difficult to
track down.

Despite spending ages on this, I haven't yet tracked down the root cause enough
to provide a patch.

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to