www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 3325] New: ICE(func.c) function literal with post-contract

reply d-bugmail puremagic.com writes:
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



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: -------
Sep 17 2009
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3325


Don <clugdbug yahoo.com.au> changed:

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



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: -------
Sep 20 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3325


Don <clugdbug yahoo.com.au> changed:

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



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: -------
Sep 23 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3325




---
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: -------
Sep 25 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3325






 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: -------
Sep 25 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3325


Sobirari Muhomori <maxmo pochta.ru> changed:

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



---
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: -------
Sep 25 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3325


Don <clugdbug yahoo.com.au> changed:

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





 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: -------
Sep 25 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3325


Don <clugdbug yahoo.com.au> changed:

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





 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: -------
Sep 29 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3325




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: -------
Sep 29 2009
prev sibling parent d-bugmail puremagic.com writes:
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



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: -------
Oct 13 2009