I was thrilled to see Don's work on CTFE arrays being merged into trunk. However, it seems still rather unstable, for example, I am able to ICE DMD (current master, 0219a5f) with the following program (latest Phobos, 516de1b):

---
import std.algorithm;

size_t[] foo() {
     auto indices = new size_t[3];
     makeIndex(["b", "c", "a"], indices);
     return indices;
}

enum bar = foo();
---

The exact error message is: ?Assertion failed: ((v2->getValue()->op == TOKarrayliteral || v2->getValue()->op == TOKstring || v2->getValue()->op == TOKassocarrayliteral || v2->getValue()->op == TOKnull)), function interpretAssignCommon, file interpret.c, line 2590.?

Don, are bug reports helpful for you at the current stage? In which form do you want to receive them?

David

On 10 April 2011 01:48, David Nadlinger <code at klickverbot.at> wrote:
> I was thrilled to see Don's work on CTFE arrays being merged into trunk. However, it seems still rather unstable, for example, I am able to ICE DMD (current master, 0219a5f) with the following program (latest Phobos, 516de1b):
>
> ---
> import std.algorithm;
>
> size_t[] foo() {
> ? ?auto indices = new size_t[3];
> ? ?makeIndex(["b", "c", "a"], indices);
> ? ?return indices;
> }
>
> enum bar = foo();
> ---
>
> The exact error message is: ?Assertion failed: ((v2->getValue()->op ==
> TOKarrayliteral || v2->getValue()->op == TOKstring || v2->getValue()->op ==
> TOKassocarrayliteral || v2->getValue()->op == TOKnull)), function
> interpretAssignCommon, file interpret.c, line 2590.?
>
> Don, are bug reports helpful for you at the current stage? In which form do you want to receive them?

Yes, that's exactly what I want. I added a lot more asserts to the
code, so it will assert if it hits anything
it can't handle.
This one is a simple bug -- I've just got two tests in the wrong order.
I've pushed a fix to the ctfemem branch.

https://github.com/donc/dmd/commit/f8e9d18d37a845c95a88e9146caf1b51a66b4d55

Walter -- you could use the fork queue to apply this to both D2 and D1. If more test cases show up I'll do a separate branch.

On 4/10/11 7:26 AM, Don Clugston wrote:
> Yes, that's exactly what I want.[?]

Another ICE, with f8e9d18 applied:
---
import std.algorithm;

size_t[] foo() {
     auto e = ["b", "c", "a", "d", "e", "f", "g"];
     auto indices = new size_t[e.length];
     makeIndex(e, indices);
     return indices;
}

enum bar = foo();
---

?Assertion failed: (v2 && v2->getValue()), function interpretAssignCommon, file interpret.c, line 2575.?

Interestingly, this only seems to occur with seven elements or more ? otherwise, the ?could not sort? assert in std.algorithm sort is triggered (which is buggy in its own way, will submit a pull request for that).

David

Walter -- please do NOT use this commit, it is not correct. (The correct solution is to remove the assert entirely and leave the code as-is).


On 10 April 2011 07:26, Don Clugston <dclugston at googlemail.com> wrote:
> On 10 April 2011 01:48, David Nadlinger <code at klickverbot.at> wrote:

>> The exact error message is: ?Assertion failed: ((v2->getValue()->op ==
>> TOKarrayliteral || v2->getValue()->op == TOKstring || v2->getValue()->op ==
>> TOKassocarrayliteral || v2->getValue()->op == TOKnull)), function
>> interpretAssignCommon, file interpret.c, line 2590.?

> This one is a simple bug -- I've just got two tests in the wrong order. I've pushed a fix to the ctfemem branch.
>
> https://github.com/donc/dmd/commit/f8e9d18d37a845c95a88e9146caf1b51a66b4d55
>
> Walter -- you could use the fork queue to apply this to both D2 and D1. If more test cases show up I'll do a separate branch.
>

On 4/10/2011 4:07 PM, Don Clugston wrote:
> Walter -- please do NOT use this commit, it is not correct.

Ok.

>   (The
> correct solution is to remove the assert entirely and leave the code
> as-is).

Can you give me a diff for that?

>
> On 10 April 2011 07:26, Don Clugston<dclugston at googlemail.com>  wrote:
>> On 10 April 2011 01:48, David Nadlinger<code at klickverbot.at>  wrote:
>>> The exact error message is: ?Assertion failed: ((v2->getValue()->op ==
>>> TOKarrayliteral || v2->getValue()->op == TOKstring || v2->getValue()->op ==
>>> TOKassocarrayliteral || v2->getValue()->op == TOKnull)), function
>>> interpretAssignCommon, file interpret.c, line 2590.?
>> This one is a simple bug -- I've just got two tests in the wrong order. I've pushed a fix to the ctfemem branch.
>>
>> https://github.com/donc/dmd/commit/f8e9d18d37a845c95a88e9146caf1b51a66b4d55
>>
>> Walter -- you could use the fork queue to apply this to both D2 and D1. If more test cases show up I'll do a separate branch.
>>
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>
>

On 11 April 2011 06:17, Walter Bright <walter at digitalmars.com> wrote:
>
>
> On 4/10/2011 4:07 PM, Don Clugston wrote:
>>
>> Walter -- please do NOT use this commit, it is not correct.
>
> Ok.
>
>> ?(The
>> correct solution is to remove the assert entirely and leave the code
>> as-is).
>
> Can you give me a diff for that?

I will fix the other ICE first.

On 11 April 2011 10:02, Don Clugston <dclugston at googlemail.com> wrote:
> On 11 April 2011 06:17, Walter Bright <walter at digitalmars.com> wrote:
>>
>>
>> On 4/10/2011 4:07 PM, Don Clugston wrote:
>>>
>>> Walter -- please do NOT use this commit, it is not correct.
>>
>> Ok.
>>
>>> ?(The
>>> correct solution is to remove the assert entirely and leave the code
>>> as-is).
>>
>> Can you give me a diff for that?
>
> I will fix the other ICE first.

https://github.com/D-Programming-Language/dmd/pull/25

Another regression present in Git master (186b6a0):

---
class Foo {
     void bar() {}
}

string[] getSymbols(C)() {
     string[] result;
     foreach(s; __traits(derivedMembers, C)) {
         result ~= s;
     }
     return result;
}

enum s = getSymbols!Foo();

// Prints ?string[]: bar, length: 3u? instead of
// ?string[]: ["bar"], length: 1u?.
pragma(msg, typeof(s), ": ", s, ", length: ", s.length);

// Trying to access something fails with:
// ?integral constant must be scalar type, not string?.
enum f = s[0];
---

Somehow, s seems to refer to the element of the string[] array ("bar"), instead of to the array itself (["bar"]).

David

This turns out to be a pre-existing bug, which I've added as bug5852.
It's quite serious.
Pull request which fixes this:
https://github.com/D-Programming-Language/dmd/pull/33


On 18 April 2011 01:55, David Nadlinger <code at klickverbot.at> wrote:
> Another regression present in Git master (186b6a0):
>
> ---
> class Foo {
> ? ?void bar() {}
> }
>
> string[] getSymbols(C)() {
> ? ?string[] result;
> ? ?foreach(s; __traits(derivedMembers, C)) {
> ? ? ? ?result ~= s;
> ? ?}
> ? ?return result;
> }
>
> enum s = getSymbols!Foo();
>
> // Prints ?string[]: bar, length: 3u? instead of
> // ?string[]: ["bar"], length: 1u?.
> pragma(msg, typeof(s), ": ", s, ", length: ", s.length);
>
> // Trying to access something fails with:
> // ?integral constant must be scalar type, not string?.
> enum f = s[0];
> ---
>
> Somehow, s seems to refer to the element of the string[] array ("bar"),
> instead of to the array itself (["bar"]).
>
> David
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 4/18/11 11:06 PM, Don Clugston wrote:
> This turns out to be a pre-existing bug, which I've added as bug5852.
> It's quite serious.
> Pull request which fixes this:
> https://github.com/D-Programming-Language/dmd/pull/33

Thanks a lot for the amazing pace at which you are fixing bugs, Don!

Here is another regression:

---
int foo() {
     string[] strings;
     foreach (s; strings) {}
     return 0;
}

enum bar = foo();
---

While the foreach loop would just be executed zero times for null arrays at run-time (and in 2.052), it breaks CTFE in current Git master.

David