Hey Guys,

Pointers support is coming!

The following code compiles now:

uint* fn(uint v)
{
    return new uint(v + 6);
}


static assert(*fn(5) == 11);

On Thursday, 22 December 2016 at 12:47:12 UTC, Stefan Koch wrote:
> Hey Guys,
>
> Pointers support is coming!

Awesome!

Are there any D language features working in newCTFE that doesn't work on current upstream master?

On Thursday, 22 December 2016 at 15:21:08 UTC, Nordlöw wrote:
> On Thursday, 22 December 2016 at 12:47:12 UTC, Stefan Koch wrote:
>> Hey Guys,
>>
>> Pointers support is coming!
>
> Awesome!
>
> Are there any D language features working in newCTFE that doesn't work on current upstream master?

None at the moment, the current work is aimed to provide a fast replacement for the engine. It does not aim to add any functionality to CTFE.
At least not yet.
I am planning to support closures with multiple contexts at CTFE, but that can only be worked on after everything else is working.

I just fixed the "" case for StringLiterals.
However the fix is quite hackish and needs to be revisited soon.
Furthermore I have made a few more preparations for function call support.

The reason why I am a bit reculant to enable function calls is the vast increase of bug-attack-surface.

Also there has been a slight speed-increase in the interpreter due to the removal of stack-pointers which were a left-over from the time where the heap was unimplemented.

I may restore the llvm-backend temporarily to verify the function-call handling (one I am ready to enable it).

On Thursday, 22 December 2016 at 20:34:50 UTC, Stefan Koch wrote:
> I just fixed the "" case for StringLiterals.

This exposed bugs in the code-generator because now phobos-unittests with "" are run.
(Which would previously be counted as uncompilable)
Apparently we run into a situation where the interpreter tries to fetch instructions that are out-of-range.
This can only be caused by miscompiled code.
I am investigating.

On Friday, 23 December 2016 at 10:25:57 UTC, Stefan Koch wrote:
> On Thursday, 22 December 2016 at 20:34:50 UTC, Stefan Koch wrote:
>> I just fixed the "" case for StringLiterals.
>
> This exposed bugs in the code-generator because now phobos-unittests with "" are run.
> (Which would previously be counted as uncompilable)
> Apparently we run into a situation where the interpreter tries to fetch instructions that are out-of-range.
> This can only be caused by miscompiled code.
> I am investigating.

Seems like that one was triggerd by random garbage being written into empty strings :)
Empty string literals are now fixed for good.

On Friday, 23 December 2016 at 11:31:14 UTC, Stefan Koch wrote:
> On Friday, 23 December 2016 at 10:25:57 UTC, Stefan Koch wrote:
>> On Thursday, 22 December 2016 at 20:34:50 UTC, Stefan Koch wrote:
>>> I just fixed the "" case for StringLiterals.
>>
>> This exposed bugs in the code-generator because now phobos-unittests with "" are run.
>> (Which would previously be counted as uncompilable)
>> Apparently we run into a situation where the interpreter tries to fetch instructions that are out-of-range.
>> This can only be caused by miscompiled code.
>> I am investigating.
>
> Seems like that one was triggerd by random garbage being written into empty strings :)
> Empty string literals are now fixed for good.

I just made global enums and static immutables visible to newCTFE.
Before they would trigger a bailout since they are not defined in the functions stack-frame.

meaning this compiles now:
uint[] arrayLiteralReturn()
{
  return [1,2,3];
}
static immutable alr = arrayLiteralReturn();
static assert(alr == [1,2,3]);

Some progress on && has been made.
It can now be used within an if.
It is only enabled if debug = andnd is given.

On Saturday, 24 December 2016 at 16:10:04 UTC, Stefan Koch wrote:
> Some progress on && has been made.
> It can now be used within an if.
> It is only enabled if debug = andnd is given.

This introduced a bug which is now fixed.
Furthermore returning of 64bit integral values has now been enabled.
I just thought about a way to enable slices with less "CTFE-runtime" support.
This is a good thing since the CTFE runtime currently is made up of a few pretty long macros.
That bloat the bytecode beyond recognition.
As soon as call are supported they can be turned into function-calls.
However function calls are pretty expensive.
Therefore it would be good if lightweight slice handling would work.

> static immutable alr = arrayLiteralReturn();
> static assert(alr == [1,2,3]);

There were a few problems with that.
Namely some arrays-literals would not have a length.
This is because of literals coercing to slices.
This bug is now fixed, at the expense of registering more types then is strictly necessary.
Also it creates null holes in the TypeArrays.
This may might be painful in the future.
But for now, global Array-literals work.