CTFE Status 2

[Stefan Koch via Digitalmars-d]

On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
> [ ... ]

Hey Guys I just fixed an ABI issue concerning slices and structs.

This issue took 2.5 weeks to find and fix.

So let me describe what was going on.
As you may know newCTFE defines it's own ABI (since it is a 
platform in it's own right)
Slices are generally represented as 16Byte SliceDescriptors
of the form
struct SliceDesc
{
   uint Base; // T* really. but always 4 bytes regardless
   uint Length;
   uint Capcity; // unused for now.
   uint ExtraFlags // unused will be important for array-casts
}

Whereas A struct is always stored __packed__ and aligned to 4 
byte boundaries

struct S // size: 20
{
   ubyte m1; // offset: 0
   ulong m2; // offset: 4
   ubyte m3; // offset: 12
   ubyte m4; // offset: 16
}

Now Slices inside of structs are stored by injecting the 
corresponding sliceDescriptor
Meaning:
AS { uint[] a; uint aLen; } => {  uint[4] aDesc; uint aLen }
However the code that is repsonsible for converting newCTFE-ABI 
values to DMD-expressions was still assuming this data-layout
AS { uint[] a; uint aLen; } => { (uint[4])* aDescPtr; uint aLen }
which caused it to do an extra derefence and and actually 
interpreting the sliceBase as a descriptor pointer.

Which of course produced complete garbage.

The reason why this took me so long to fix is because I suspected 
that the conversion was using the new convention and the 
byte-code generator was at fault.
And in my attemptes to fix the bytecode generation I introduced 
even more ABI bugs.

long story short:
This is now fixed.
and
ABI bugs are HELL!

Cheers,
Stefan