6599 – ICE(constfold.c) On use of invalid expression as a compile-time initializer

Compiling the following code results in a bus error:
class Orbit
{
 Repository repository = Repository();
}
struct Repository
{
 string fileProtocol = "file://";
 string source = fileProtocol ~ "/usr/local/orbit/repository";
}
void main () {}
DMD 1.069 and 2.054
Mac OS X 10.6.8
GDB session:
(gdb) r 
Starting program: /Users/doob/.dvm/compilers/dmd-1.069/bin/dmd test.d
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
0x000529b0 in InterfaceDeclaration::~InterfaceDeclaration ()
(gdb) bt
#0 0x000529b0 in InterfaceDeclaration::~InterfaceDeclaration ()
#1 0x000caef8 in TypeTypeof::~TypeTypeof ()
#2 0x000cac0d in TypeTypeof::~TypeTypeof ()
#3 0x000097b8 in StaticIfDeclaration::~StaticIfDeclaration ()
#4 0x0000a930 in StaticIfDeclaration::~StaticIfDeclaration ()
#5 0x00057aee in TemplateParameters::~TemplateParameters ()
#6 0x0002958b in ErrorExp::~ErrorExp ()
#7 0x000b9992 in StructInitializer::~StructInitializer ()
#8 0x000b72d8 in StructInitializer::~StructInitializer ()
#9 0x0000219f in ?? ()
#10 0x000020cd in ?? ()
(gdb)

That's a strange place to get the error. I get an AV at constfold.c:1396.
CatExp::optimize calls :optimize on fileProtocol (which does nothing) then passes it along to Cat, which crashes trying to access fileProtocol's type.
It seems to happen for all operators:
class Orbit
{
 Repository repository = Repository();
}
struct Repository
{
 //int source = xx ~ xx;
 //int source = xx + xx;
 //int source = xx - xx;
 //int source = xx * xx;
 //int source = xx / xx;
 //int source = xx ^^ xx;
 //int source = xx & xx;
 int source = xx | xx;
}
void main () {}
It is probably invalid to assume e->type has been set inside Cat and other constfold functions.

(In reply to comment #1)
> That's a strange place to get the error. I get an AV at constfold.c:1396.
> 
> CatExp::optimize calls :optimize on fileProtocol (which does nothing) then
> passes it along to Cat, which crashes trying to access fileProtocol's type.
> 
> It seems to happen for all operators:
[snip] 
> It is probably invalid to assume e->type has been set inside Cat and other
> constfold functions.
No, it's valid. Those functions should only be called after the semantic pass was completed successfully on the expression. This is yet another gagging system bug.
Repository is forward referenced from Orbit. Semantic is run on Repository with errors gagged. This semantic pass fails, but leaves Repository's members in an invalid state.
If you move Orbit after Repository, you see the correct error messages.

(In reply to comment #2)
> (In reply to comment #1)
> > That's a strange place to get the error. I get an AV at constfold.c:1396.
> > 
> > CatExp::optimize calls :optimize on fileProtocol (which does nothing) then
> > passes it along to Cat, which crashes trying to access fileProtocol's type.
> > 
> > It seems to happen for all operators:
> [snip] 
> > It is probably invalid to assume e->type has been set inside Cat and other
> > constfold functions.
> 
> No, it's valid. Those functions should only be called after the semantic pass
> was completed successfully on the expression. This is yet another gagging
> system bug.
> 
> Repository is forward referenced from Orbit. Semantic is run on Repository with
> errors gagged. This semantic pass fails, but leaves Repository's members in an
> invalid state.
> If you move Orbit after Repository, you see the correct error messages.
Ok. That would make this another case of bug 4269?

With DMD 1.069 I get the same error even when I place Repository before Orbit.

(In reply to comment #3)
> (In reply to comment #2)
> > This is yet another gagging system bug.
> > 
> > Repository is forward referenced from Orbit. Semantic is run on Repository with
> > errors gagged. This semantic pass fails, but leaves Repository's members in an
> > invalid state.
> > If you move Orbit after Repository, you see the correct error messages.
> 
> Ok. That would make this another case of bug 4269?
They have the same kind of structural cause in the compiler, but I think they don't have any of the same code in common. It's definitely not a duplicate.

https://github.com/D-Programming-Language/dmd/commit/6dc84fd7f2f43d28039d08bf80658cffc97e00f0
https://github.com/D-Programming-Language/dmd/commit/cf7a78423f426fb0d2d62b0af821129f1a4077a1