CTFE Status 2

[Stefan Koch via Digitalmars-d]

On Monday, 5 June 2017 at 20:51:03 UTC, Stefan Koch wrote:
> On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch 
> wrote:
>> [ .. ]
>
> Hi Guys,
>
> I am still working on the buggy Slice-Assignment.
> Just now I fixed a bug where an [Bytecode-Assert]
> would flip it's the condition ... and trigger whenever it was 
> true instead of false.
> Assertions are one of things which cannot be tested at 
> compiletime since they need to interact with dmd.... bummer.
>
> Originally I intended for floating-point support to be 
> implemented in this and the following month. Looks like I am 
> not gonna make it.
>
> My main system is waiting for replacement parts.
> And as you know my laptop cannot link dmd when a gui is 
> active... so that's not great either.
>
> Cheers,
> Stefan

I solved the slice assignment case.
Now here is a subtle bug for you.

As you may know, newCTFE has it's own type-system in order to 
help make the IR simpler.
Later on typed version of the ir gets lowered though until only 
int32 expressions remain.
When processing Slice expression I lowered to early though, and 
returned an i32 to be interpreted as pointer to a slice 
descriptor.
However in the slice-assignment code I wanted to the the 
elmementType form the SliceExp, which came back as 
BCType(invalid).
Then I took it the size of it, which came back as 0. (an invalid 
size for an invalid type).
And multiplied the index and length, with it to move to the 
correct point in the slice-buffer.

That comes back as target[0 .. 0] = source[0 .. 0].
So no modification occurs.

Time to find this: roughly 2 weeks.

Why did it take so long ?
Because I thought the ABI was at fault; And spent a lot of time 
staring on memory dumps :(