www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 2437] New: ICE - Assertion failure: default struct argument

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2437

           Summary: ICE - Assertion failure: default struct argument
           Product: D
           Version: 2.019
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Keywords: ice-on-invalid-code, ice-on-valid-code
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla digitalmars.com
        ReportedBy: s.d.hammett googlemail.com


Compiling the following code with 2.019, 2.020

struct aStruct{
        int     m_Int;

        this(int a){
                m_Int = a;
        }
}

class aClass{
        void aFunc(aStruct a = aStruct(44)){
        }
}

int main(string argv[]) {
        aClass a = new aClass();
        a.aFunc();
        return 0;
}

Gives:

ICE - Assertion failure: '!needThis()' on line 166 in file 'tocsym.c'

Not sure if this code is valid or invalid.


-- 
Oct 31 2008
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2437


clugdbug yahoo.com.au changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jlquinn optonline.net




------- Comment #1 from clugdbug yahoo.com.au  2009-05-04 07:50 -------
*** Bug 2440 has been marked as a duplicate of this bug. ***


-- 
May 04 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2437





--- Comment #2 from Don <clugdbug yahoo.com.au>  2009-09-02 12:11:01 PDT ---
The root cause is in func.c, FuncDeclaration::semantic(Scope *sc)

Around line 240, we read:

    sd = parent->isStructDeclaration();
    if (sd)
    {
    if (isCtorDeclaration())
    {
        return;    // <============== this is a problem!
    }

Returning at this point means that the scope isn't saved. This prevents the
later semantic passes from running, in certain cases. Commenting out the return
prevents the ICE. I haven't yet checked this patch on the test suite, it could
be that additional changes are required. But the problems begin here.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 02 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2437


Don <clugdbug yahoo.com.au> changed:

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




--- Comment #3 from Don <clugdbug yahoo.com.au>  2009-09-03 00:28:53 PDT ---
Aargh, patch is incorrect. I think the patch does fix a genuine problem (it
seems to be necessary to allow you to evaluate a struct constructor in CTFE),
but there's a second problem as well.

It may be because a struct constructor such as aStruct(44) turns into 
((aStruct __ctmp2;) , __ctmp2).this(44)

And that __ctmp2 is a funny beast. Where is it stored? Its parent is the
*MODULE*, not the function it's called from. But it's not a static variable.
Weird.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 03 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2437


Rob Jacques <sandford jhu.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sandford jhu.edu


--- Comment #4 from Rob Jacques <sandford jhu.edu> 2009-10-05 21:01:26 PDT ---
Now at line 170 in DMD 2.033.
Note, this bug only applies to struct constructors and not default arguments
using static opCall or opAssign.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 05 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2437



--- Comment #5 from Don <clugdbug yahoo.com.au> 2010-04-12 13:51:13 PDT ---
See also the closely related bug 2935.
I can patch this (against svn 433) with these two changes (and the DMD test
suite still passes), which basically just remove the checks, in the case where
a CTFE variable is used. I'm not certain these patches are correct, though.


-- PATCH ------------------------------------------
tocsym.c, line 170:

Symbol *VarDeclaration::toSymbol()
{
    //printf("VarDeclaration::toSymbol(%s)\n", toChars());
    //if (needThis()) *(char*)0=0;
+    if (!isCTFE())
        assert(!needThis());


and secondly, in e2ir.c, SymbolExp::toElem() line 664:

    //printf("SymbolExp::toElem('%s') %p\n", toChars(), this);
    //printf("\tparent = '%s'\n", var->parent ? var->parent->toChars() :
"null");
-    if (op == TOKvar && var->needThis())
+    if (op == TOKvar && var->needThis() && !v->isCTFE())
    {
        error("need 'this' to access member %s", toChars());
        return el_long(TYint, 0);
    }

---------------------------------

A totally different (and probably better) alternative would be to fix it in
expression.c, around line 6770, when the temporary variable is created. If
(!sc->func), it's being created in global scope, and should be neither in
STCfield nor STCextern storage class. But I'm not sure how this should be done.

            // First look for constructor
            if (ad->ctor && arguments && arguments->dim)
            {
                // Create variable that will get constructed
                Identifier *idtmp = Lexer::uniqueId("__ctmp");
                VarDeclaration *tmp = new VarDeclaration(loc, t1, idtmp, NULL);
                tmp->storage_class |= STCctfe;
+                if (!sc->func) { 
+   // it's being created in global scope. Do something!!

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 12 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2437


Don <clugdbug yahoo.com.au> changed:

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


--- Comment #6 from Don <clugdbug yahoo.com.au> 2010-04-14 07:52:15 PDT ---
The code I've previously posted is definitely incorrect. The problem here is
that the compiler's thinks that the struct is a field of the parent; and this
happens because the scope is wrong.

I'm really not sure where to fix this. One possibility is to add it to
CommaExp::semantic, creating a new scope whenever there's a declaration which
isn't in module scope. But I think the correct solution is to change the scope
for evaluating the default arguments, in mtype.c
around line 4766; 


        /* Create a scope for evaluating the default arguments for the
parameters
         */
        Scope *argsc = sc->push();
        argsc->stc = 0;                 // don't inherit storage class
        argsc->protection = PROTpublic;
+        /* Compiler-generated comma expressions (such as struct constructors)
+         * can include a variable declaration. This declaration needs to go
somewhere.
+         * If we're inside a function, it can become a local variable of that
function;
+         * but if not (for example, if it is a function default parameter), it
needs
+         * its own scope.
+         */
+        if (!argsc->func) // not a nested function
+          argsc->parent = (Dsymbol*)sc->module;

But I don't know if it's OK to set the parent in this way. The cast is needed
only because mtype.c doesn't have the real definition of Module.
The patch to bug 2935 is required in addition to this one.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 14 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2437


Walter Bright <bugzilla digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla digitalmars.com


--- Comment #7 from Walter Bright <bugzilla digitalmars.com> 2010-04-27
09:06:41 PDT ---
I think the correct solution is identified in 2935.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 27 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2437



--- Comment #8 from Walter Bright <bugzilla digitalmars.com> 2010-04-27
11:37:19 PDT ---
changeset 452

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 27 2010
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2437


Don <clugdbug yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


--- Comment #9 from Don <clugdbug yahoo.com.au> 2010-05-05 19:04:12 PDT ---
Fixed DMD2.044

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