Bug 2935 – ICE(out.c) using struct with constructor as function default argument
Status
RESOLVED
Resolution
FIXED
Severity
normal
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
x86
OS
Windows
Creation time
2009-05-04T09:12:00Z
Last change time
2015-06-09T01:26:26Z
Keywords
ice-on-valid-code, patch
Assigned to
nobody
Creator
clugdbug
Comments
Comment #0 by clugdbug — 2009-05-04T09:12:52Z
This is a variation of bug 2437, but ICEs in a completely different place.
---
struct Foo{
int z;
this(int a){z=a;}
}
void bar(Foo a = Foo(1)){ }
void foo() { bar(); }
---
Internal error: ..\ztc\out.c 1199
Comment #1 by clugdbug — 2009-09-02T12:15:57Z
Same root cause as bug 2437, and the same simple patch fixes it.
Comment #2 by clugdbug — 2009-09-03T00:29:40Z
Not patched yet, see bug 2437 for details.
Comment #3 by sandford — 2009-10-05T21:03:51Z
Note that struct defaults using either opAssign or static opCall do not seem to be affected by this bug.
Comment #4 by clugdbug — 2009-10-14T07:45:46Z
*** Issue 3399 has been marked as a duplicate of this issue. ***
Comment #5 by 2korden — 2009-12-25T07:15:59Z
*** Issue 3648 has been marked as a duplicate of this issue. ***
Comment #6 by clugdbug — 2010-04-12T13:01:45Z
PATCH:
I think it's enough to change tocsym.c, VarDeclaration::toSymbol(),
around line 201. If it's a CTFE variable, it's shouldn't be marked as an extern.
t->Tcount++;
- if (isDataseg())
+ if (isDataseg() && !isCTFE())
{
if (isThreadlocal())
{ /* Thread local storage
*/
TYPE *ts = t;
ts->Tcount++; // make sure a different t is allocated
Comment #7 by bugzilla — 2010-04-27T08:49:55Z
The problem is a semantic one. Default arguments are evaluated in the context of the function declaration, not where it's used. So, the temporary generated by the constructor is created in global space!
The patch tries to force it back into the function scope, but that doesn't work as you can see if you change foo() to:
void foo() { bar(); bar(); }
as it fails trying to allocate the same symbol twice. Not sure what the correct solution is at the moment.
Comment #8 by bugzilla — 2010-04-27T09:04:17Z
The problem is the code here in expression.c funcParameters():
arg = p->defaultArg;
arg = arg->copy(); <-- Danger, Will Robinson!
arg = arg->resolveLoc(loc, sc);
arguments->push(arg);
The arg->copy() is the problem, as it will copy any DeclarationExp's resulting in multiple declarations with the same name. A correct fix will be to do what DeclarationExp::doInline() does, which is for any non-static declarations, create another declaration.
A new expression tree walker has to be built to accomplish this. Perhaps a good approach is to create a generic walker that accepts a lambda function to operate on each node.