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

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=3010

Mike Franklin  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=2672

--

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

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=3010

Andrei Alexandrescu and...@erdani.com changed:

   What|Removed |Added

Version|2.029   |D2

--

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

[d-bugmail]

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


Don clugd...@yahoo.com.au changed:

   What|Removed |Added

   Keywords||patch




--- Comment #2 from Don clugd...@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: ---

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

[d-bugmail]

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





--- Comment #1 from Don clugd...@yahoo.com.au  2009-05-24 13:24:23 PDT ---
I making really slow progress on this, so am including a progress update.

In mtype.c, TypeNext::makeInvariant(), there's a line:

if (ty != Tfunction  ty != Tdelegate  next-deco 
!next-isInvariant())
{t-next = next-invariantOf();

But in the case where 'next' was created by auto type deduction, next-deco is
NULL, so next-invariantOf() never gets called, and we get a malformed
immutable type. I haven't yet worked out why next-deco is NULL when next is a
TypeFunction which was created through type inference. It could be  because it
began life as a TypeSymOff?

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