Created attachment 1582
code
http://ideone.com/dJR9M3
The attached code generates:
1 2 3
1 2 3
1 2 3
1 0 0
0 2 0
0 0 3
When it should generate:
1 0 0
0 2 0
0 0 3
1 0 0
0 2 0
0 0 3
Seems there's some sort of issue that assigns all the values for one "A" all the same value.
Comment #1 by ag0aep6g — 2016-02-14T22:19:01Z
Reduced a little further:
----
struct A {float value;}
struct S
{
A[2] values;
this(float)
{
values[0].value = 0;
values[1].value = 1;
}
}
void main()
{
{
auto s = S(1.0f);
assert(s.values[0].value == 0); /* passes */
assert(s.values[1].value == 1); /* passes */
}
{
enum s = S(1.0f);
assert(s.values[0].value == 0); /* fails */
assert(s.values[1].value == 1); /* passes */
}
}
----
Works with 2.066. Fails since 2.067.
Comment #5 by github-bugzilla — 2016-02-23T11:02:10Z
Commits pushed to stable at https://github.com/D-Programming-Language/dmdhttps://github.com/D-Programming-Language/dmd/commit/1d13794bc84a6af0d13f84a16baf6f881109668e
fix Issue 15681 - Nested user type enum not retaining value properly
1. It was a bug in `createBlockDuplicatedArrayLiteral` function. On array literal construction, the element should be copied when the type has value semantics and the CTFE value has sub payload.
2. Also the `createBlockDuplicatedArrayLiteral` callers need to handle the `elem` argument ownership well.
2a. In `copyLiteral`, it didn't copy the source struct element on block assignment. 2b. In `recursivelyCreateArrayLiteral`, the `elemType.defaultInitLiteral(loc)` is not yet CTFE-ed expression. So it should be interpreted to copy it into CTFE world.
https://github.com/D-Programming-Language/dmd/commit/21c35b077388429de36f6f8d63063d4a6a35facd
Merge pull request #5462 from 9rnsr/fix15681
[REG2.067] Issue 15681 - Nested user type enum not retaining value properly
Comment #6 by github-bugzilla — 2016-02-24T02:55:31Z