Bug 6681 – struct constructor call is converted to struct literal that breaks union initialization
Status
RESOLVED
Resolution
FIXED
Severity
regression
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2011-09-16T10:42:00Z
Last change time
2015-06-09T05:11:40Z
Keywords
rejects-valid
Assigned to
yebblies
Creator
fawzi
Comments
Comment #0 by fawzi — 2011-09-16T10:42:44Z
In D1 code like this
{{{
module t;
template MTuple( TList... )
{
alias TList MTuple;
}
struct V{
union {
double[2] cell;
version(v2) {} else {
MTuple!(double,double) tuple;
}
struct {
union { double x; double r; }
union { double y; double g; }
}
}
static const V zero={x:0, y:1};
}
V a=V.zero;
version(v2) {
struct Q {
union {
struct {
double x, y;
}
V xyzw;
}
const static Q id = { x: 0, y:1 };
}
Q b=Q.id;
}
}}}
fails with duplicate union initialization, which is incorrect.
This happens both with and without -version=v2 which shows that the error is not just the tuple.
Closely related errors are present also in D2, even if one uses constructors:
{{{
module t;
template MTuple( TList... )
{
alias TList MTuple;
}
struct V{
this(double a,double b){
x=a;
y=b;
}
union {
double[2] cell;
version(v2) {} else {
MTuple!(double,double) tuple;
}
struct {
union { double x; double r; }
union { double y; double g; }
}
}
static immutable V zero=V(0,1);
}
V a=V.zero;
version(v2) {
struct Q {
union {
struct {
double x, y;
}
V xyzw;
}
immutable static Q id =Q(0,1);
}
Q b=Q.id;
}
}}}
similar errors seem to be very old:
http://www.digitalmars.com/d/archives/digitalmars/D/bugs/6271.html
and there are related or very similar errors are already present in bugzilla:
http://d.puremagic.com/issues/show_bug.cgi?id=4241 which basically uses the same code as me (omg derived vector structs), but just complains about line number, seemingly accepting the error (which is bogus imho.
I have also tried to sprinkle around some =void but I just managed to end up with "Error: no initializer for union".
http://d.puremagic.com/issues/show_bug.cgi?id=1432 (using initializers in the union)
but this one at least with D1 is a regression from 1.067 at least
Comment #1 by bugzilla — 2011-10-24T20:57:25Z
There have been several patches to 'fix' struct/union initialization. Evidently, we need to step back a bit and rethink/reengineer it. Something along the lines of:
1. Create a list of all the fields, in lexical order. Each field will have a beginning offset and an ending offset. One field 'overlaps' another if its offset range overlaps the other.
2. Examine list of initializers. Unnamed initializers will be associated with a field as follows:
1. if it's the first initializer, it's the first field. Done.
2. start with the previous field that was initialized. Move forward through
the field list and pick the first field that does not overlap with that
previous field. That will be the field associated with that initializer.
3. If any initialized field overlaps with any other initialized field, error.
4. Go back through the field list again, in order. If a field does not have an initializer, and does not overlap with any other initialized field, assign it the default initializer.
At this point, I wish to defer this to the next update.
Comment #2 by yebblies — 2012-02-01T03:58:33Z
Ok, the first test case reduces to this:
struct V{
union {
double[2] cell;
double x;
}
static immutable V zero=V(0,1);
}
The problem being that the struct literal gets turned into:
this(a, b) { cell = 0; x = 1; }
ie. it passes the first argument to the first member, and the second argument to the second.
This is sort of what I'd expect to happen, but the error message is completely valid for what it's trying to do. If anyone has a better idea of how struct literals should map to unions, please open another bug report about it.
Comment #3 by yebblies — 2012-02-01T04:10:11Z
Got my test cases a little mixed up there, but it's still mostly valid.
All of the non-struct-literal struct construction seems to be converted into struct literals. eg.
struct S
{
this(int a, int b) { this.a = b; this.b = a; }
union {
ulong g;
struct {int a, b; };
}
}
static immutable S s = S(0, 1);
Prints: (with a little extra debug output)
StructLiteralExp::semantic('S(0LU,1,0)')
S
Error: duplicate union initialization for a
Error: duplicate union initialization for b
As you can see, it make a struct literal with every field accounted for.
So this is a bug in the constfolding/ctfe code.
Comment #4 by clugdbug — 2012-02-01T04:18:34Z
(In reply to comment #3)
>
> As you can see, it make a struct literal with every field accounted for.
>
> So this is a bug in the constfolding/ctfe code.
Not exactly. It's a compiler structural problem: there's no way to specify a struct literal with missing fields. Struct static initializers can do it, but struct literals cannot.
I think the solution is to merge struct literals with struct static initializers, as it says in a TODO in the code.
Comment #5 by yebblies — 2012-02-01T05:02:06Z
(In reply to comment #4)
> Not exactly. It's a compiler structural problem: there's no way to specify a
> struct literal with missing fields. Struct static initializers can do it, but
> struct literals cannot.
>
> I think the solution is to merge struct literals with struct static
> initializers, as it says in a TODO in the code.
One of the D1 cases seems to have the same problem with struct static initializers. Can't this be done by just nulling out the untouched fields in the Expressions array and ensuring at least one field gets initialized?
Comment #6 by clugdbug — 2012-02-01T07:13:36Z
(In reply to comment #5)
> (In reply to comment #4)
> > Not exactly. It's a compiler structural problem: there's no way to specify a
> > struct literal with missing fields. Struct static initializers can do it, but
> > struct literals cannot.
> >
> > I think the solution is to merge struct literals with struct static
> > initializers, as it says in a TODO in the code.
>
> One of the D1 cases seems to have the same problem with struct static
> initializers. Can't this be done by just nulling out the untouched fields in
> the Expressions array and ensuring at least one field gets initialized?
Maybe. The order of fields in a struct is fixed, so in theory that ought to work.
It's a while since I last looked at it, but I remember there were severe problems with anonymous unions nested inside anonymous unions. There's code elsewhere in the compiler which tries to identify fields based on their type + offset, but that cannot work. It appears to work at the moment, but only because it assumes when fields are initialized in order with no gaps.
Still, I've fixed some of those compiler bugs recently, so maybe it's more possible now.
Comment #7 by yebblies — 2012-02-01T08:38:36Z
Ok, I'll take a look at it tomorrow unless you want it. I know there are at least two places it checks for overlapping union initialization, one in expression.c and one somewhere in the glue, maybe e2ir?
Comment #8 by clugdbug — 2012-02-02T03:26:11Z
(In reply to comment #7)
> Ok, I'll take a look at it tomorrow unless you want it. I know there are at
> least two places it checks for overlapping union initialization, one in
> expression.c and one somewhere in the glue, maybe e2ir?
The big one is in init.c. Around line 340 there's code I wrote (to replace the code in 320..340). Walter disabled that code a bit later, but he didn't say why.
Would be great if you could take a fresh look at it.
Comment #9 by yebblies — 2012-02-17T02:07:11Z
I think for this to work, the interpreter needs to be able to handle uninitialized values, and unions need to default to void initializers. I have a patch for this that is nearly ready, and solves issue 6438 at the same time.
Comment #10 by bugzilla — 2012-03-03T21:30:50Z
>It's a compiler structural problem: there's no way to specify a
struct literal with missing fields.
I don't know about in CTFE, but in the rest of the compiler the code is in place to just have elements[i] be NULL for missing fields.
Comment #11 by yebblies — 2012-03-03T21:45:03Z
(In reply to comment #10)
> >It's a compiler structural problem: there's no way to specify a
> struct literal with missing fields.
>
> I don't know about in CTFE, but in the rest of the compiler the code is in
> place to just have elements[i] be NULL for missing fields.
I have branch for this that mostly works, but no time to work on it at the moment.
https://github.com/yebblies/dmd/tree/ctfeunion