Thread overview
[Issue 3325] New: ICE(func.c) function literal with post-contract
Sep 17, 2009
Kasumi Hanazuki
Sep 20, 2009
Don
Sep 23, 2009
Don
Sep 25, 2009
Sobirari Muhomori
Sep 25, 2009
Don
Sep 25, 2009
Sobirari Muhomori
Sep 25, 2009
Don
Sep 30, 2009
Don
Sep 30, 2009
Don
Oct 13, 2009
Walter Bright
September 17, 2009
http://d.puremagic.com/issues/show_bug.cgi?id=3325

           Summary: ICE(func.c) function literal with post-contract
           Product: D
           Version: 2.032
          Platform: x86
        OS/Version: Windows
            Status: NEW
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: k.hanazuki@gmail.com


--- Comment #0 from Kasumi Hanazuki <k.hanazuki@gmail.com> 2009-09-17 07:14:19 PDT ---
Windows DMD 2.032

Function/delegate literal with post-contract causes the error:
    Assertion failure: 'type->nextOf()' on line 927 in file 'func.c'

It compiles and seems working correctly when there is only pre-condition.

----

void main() {
    function() body { }; // fine
    function() in { } body { }; // fine
    function() out { } body { }; // error
    function() in { } out { } body { }; // error

    delegate() body { }; // fine
    delegate() in { } body { }; // fine
    delegate() out { } body { }; // error
    delegate() in { } out { } body { }; // error
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
September 20, 2009
http://d.puremagic.com/issues/show_bug.cgi?id=3325


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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |clugdbug@yahoo.com.au


--- Comment #1 from Don <clugdbug@yahoo.com.au> 2009-09-20 12:37:58 PDT ---
This ICE is because it needs to know the return type, before it can create the result variable for the post-condition. Creation of the result variable should probably happen in ReturnStatement::semantic, and the semantic for the post-condition run _after_ the function semantic, instead of before.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
September 23, 2009
http://d.puremagic.com/issues/show_bug.cgi?id=3325


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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|2.032                       |1.00


--- Comment #2 from Don <clugdbug@yahoo.com.au> 2009-09-23 00:04:31 PDT ---
This has also been present on D1, since dinosaurs walked the earth. ICEs on DMD0.175, for example.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
September 25, 2009
http://d.puremagic.com/issues/show_bug.cgi?id=3325



--- Comment #3 from Sobirari Muhomori <maxmo@pochta.ru> 2009-09-25 05:50:49 PDT ---
Hmm... is dmd able to preserve contract info in function pointer type?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
September 25, 2009
http://d.puremagic.com/issues/show_bug.cgi?id=3325



--- Comment #4 from Don <clugdbug@yahoo.com.au> 2009-09-25 05:52:00 PDT ---
(In reply to comment #3)
> Hmm... is dmd able to preserve contract info in function pointer type?

No, but this is a function literal, not a function pointer.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
September 25, 2009
http://d.puremagic.com/issues/show_bug.cgi?id=3325


Sobirari Muhomori <maxmo@pochta.ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Depends on|                            |302


--- Comment #5 from Sobirari Muhomori <maxmo@pochta.ru> 2009-09-25 05:59:04 PDT ---
But literals do not simply exist, they must be used somehow. And contracts should work somehow. It was questioned in bug 302, whether contracts should be called by caller or callee. So this bug can be blocked by 302.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
September 25, 2009
http://d.puremagic.com/issues/show_bug.cgi?id=3325


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

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Depends on|302                         |


--- Comment #6 from Don <clugdbug@yahoo.com.au> 2009-09-25 06:39:29 PDT ---
(In reply to comment #5)
> But literals do not simply exist, they must be used somehow. And contracts should work somehow. It was questioned in bug 302, whether contracts should be called by caller or callee. So this bug can be blocked by 302.

No. That would be a general change to how contracts are done, and is nothing to do with this bug. Contracts work perfectly fine on function literals. It's just this case where return type inference is involved where we get a failure in out contacts.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
September 30, 2009
http://d.puremagic.com/issues/show_bug.cgi?id=3325


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

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


--- Comment #7 from Don <clugdbug@yahoo.com.au> 2009-09-29 23:52:50 PDT ---
(In reply to comment #1)
> This ICE is because it needs to know the return type, before it can create
the result variable for the post-condition. Creation of the result variable should probably happen in ReturnStatement::semantic, and the semantic for the
> post-condition run _after_ the function semantic, instead of before.

That wouldn't actually work, because there may be more than one return statement -- the result variable needs to be added at the start of the function. Maybe it's better for now to simply disallow postconditions on functions with type inference return statements, turning it from an ICE into an obscure rejects-valid.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
September 30, 2009
http://d.puremagic.com/issues/show_bug.cgi?id=3325



--- Comment #8 from Don <clugdbug@yahoo.com.au> 2009-09-29 23:52:57 PDT ---
Here is a trivial patch to prevent the ICE, and turn it into a rejects-valid. That's probably enough for now -- the fact that it's taken years for this bug to be reported shows that it's pretty obscure.

func.c, FuncDeclaration::semantic3(), around line 995.

    if (fensure || addPostInvariant())
    {   /* fensure is composed of the [out] contracts
         */
        ScopeDsymbol *sym = new ScopeDsymbol();
        sym->parent = sc2->scopesym;
        sc2 = sc2->push(sym);
+        if (!type->nextOf()) {
+         error("Postconditions are not supported if the return type is
inferred");
+         return;
+        }
        if (type->nextOf() && type->nextOf()->ty == Tvoid)
        {
        if (outId)
            error("void functions have no result");
        }

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
October 13, 2009
http://d.puremagic.com/issues/show_bug.cgi?id=3325


Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |bugzilla@digitalmars.com
         Resolution|                            |FIXED


--- Comment #9 from Walter Bright <bugzilla@digitalmars.com> 2009-10-13 13:47:52 PDT ---
Fixed dmd 1.049 and 2.034

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