Do you mean LDC should work around it? Or that it's something that should get fixed in the front end?
Sent from my iPhone On Aug 30, 2012, at 9:39 PM, Walter Bright <[email protected]> wrote: > That looks like a compiler bug. > > On 8/30/2012 4:00 PM, David Nadlinger wrote: >> I am currently working on ironing out the last few kinks in the LDC >> merge of the 2.060 frontend. The following snippet, a test case for >> Bugzilla issue 7974, currently doesn't work with LDC: >> >> --- >> mixin template mix7974() { >> uint _x; >> } >> >> struct Foo7974 { >> immutable fa = Foo7974(0); >> >> this(uint x) { >> _x = x; >> } >> mixin mix7974!(); >> } >> --- >> >> The problem is that the fix Walter applied to the frontend for 7974 >> causes the semantic pass, including the arrayCopy() of the mixin >> contents into the structs, to run twice, which leads to two separate >> VarDeclarations for Foo7974._x being present at codegen time: one >> instance, the one from the »forward reference« semantic run, is >> referred to by the struct constructor, the other instance from the >> second, »proper« run is e.g. what ends up in >> StructDeclaration::fields. >> >> As we tuck on IR construction metadata to field declarations in LDC, >> having two instances for the same field breaks our codegen in >> interesting ways – is this an unforeseen consequence of the fix in DMD >> and possibly a bug, or do I have to find a way to work around this in >> LDC? >> >> Thanks, >> David >> >> > > > _______________________________________________ > dmd-internals mailing list > [email protected] > http://lists.puremagic.com/mailman/listinfo/dmd-internals _______________________________________________ dmd-internals mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/dmd-internals
