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
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

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
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

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 <walter@digitalmars.com> 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
> dmd-internals@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

The first.  The compiler shouldn't emit the declaration more than once.

On Fri, Aug 31, 2012 at 10:20 PM, Jason House <jason.james.house@gmail.com> wrote:
> 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 <walter@digitalmars.com> 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
>> dmd-internals@puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-internals
> _______________________________________________
> dmd-internals mailing list
> dmd-internals@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

Filed an issue at http://d.puremagic.com/issues/show_bug.cgi?id=8626 so this doesn't get lost. Would be great if this could be fixed before the next release, as it yields to an ICE in LDC and has the potential to silently wreck havoc on DMD's behavior as well.

David
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals