[Issue 3010] ICE(mtype.c) function pointer type deduction puts compiler in corrupt state

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=3010


Don <clugdbug at yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |patch




--- Comment #2 from Don <clugdbug at yahoo.com.au>  2009-05-25 00:42:42 PDT ---
At last I have a patch. The root cause is that merge() never gets called on the
.next member of TypeNext.

In Type::merge(), there's a bit of code which is commented out:
--------
    if (!deco)
    {
    OutBuffer buf;
    StringValue *sv;

    //if (next)
        //next = next->merge();
-------
Possibly, we need a dynamic cast to reinstate it. What I've done as an
alternative is to perform the merge inside TypeNext::toDecoBuffer. Certainly,
it shouldn't be generating the type decoration for a pointer, when it hasn't
yet generated the type decoration for the type being pointed to.

I'm not sure if that's really the correct place (it might be too late), but at
least it fixes a raft of bugs. As well as both test cases for this bug and for
bug 2672 , it also fixes the very nasty ICE bug 1994.

-------
PATCH 1 (a mostly unrelated cosmetic change): mtype.c, Type::toCBuffer3(),
change 
        case MODinvariant:
        p = "invariant(";
to        
        case MODinvariant:
        p = "immutable(";
-----
PATCH 2: (mtype.c) in 
void TypeNext::toDecoBuffer(OutBuffer *buf, int flag)
  if (!next->deco) next->merge(); // add this line
  next->toDecoBuffer(buf, (flag & 0x100) ? 0 : mod);
-----

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------