Hi Guys,

I've just done a small refactoring which I have been putting off for a while now.
It should greatly help with reducing ABI bugs, and it cuts the dependencies between the DMD-dependent and the independent parts of newCTFE.

Furthermore I fixed handling of 64bit values which where truncated to 32bit in some cases.
I've found those while working on ctfe-able float-to-string conversion.

However there are still many bugs which can crash newCTFE or even worse, make it produce wrong output (most of those are related to classes and vtbl-handling).

I expect it'll take me multiple full-time days to make significant progress on the vtbl issues. Because first I'll have to get debug-system into shape. It only really works if there is just one function in the context being compiled, as virtual functions by definition require multiple functions to live in the compilation context, it makes the debug-system useless .... sigh.

Unfortunately my time budget is pretty tight this and the following months as I am also preparing a Dconf presentation.

Let's see how far I can get during the next weekends.

Cheers,

Stefan

On Sunday, 13 January 2019 at 14:47:59 UTC, Stefan Koch wrote:
> Let's see how far I can get during the next weekends.

Thanks and keep up the good work!

On Sunday, 13 January 2019 at 14:47:59 UTC, Stefan Koch wrote:
>
> Cheers,
>
> Stefan

Did you mean 2019 by any chance? ;)

Glad to see some progress though!

On Sunday, 13 January 2019 at 14:47:59 UTC, Stefan Koch wrote:
> Hi Guys,
>
> I've just done a small refactoring which I have been putting off for a while now.
> It should greatly help with reducing ABI bugs, and it cuts the dependencies between the DMD-dependent and the independent parts of newCTFE.

I'm not very familiar with the project, although I've seen the name pop up from time to time. What benefits does it provide? Is it only for DMD or will GDC/LDC make use of it too?

On Sunday, 13 January 2019 at 21:00:28 UTC, JN wrote:
> On Sunday, 13 January 2019 at 14:47:59 UTC, Stefan Koch wrote:
>> Hi Guys,
>>
>> I've just done a small refactoring which I have been putting off for a while now.
>> It should greatly help with reducing ABI bugs, and it cuts the dependencies between the DMD-dependent and the independent parts of newCTFE.
>
> I'm not very familiar with the project, although I've seen the name pop up from time to time. What benefits does it provide? Is it only for DMD or will GDC/LDC make use of it too?

It will benefit all compiler which chose to use the frontend of DMD.
That includes GDC and LDC.
It will also benefit the D programming language as a whole in a less tangible way, but I don't want to spoil it before Dconf :)

Cheers,
Stefan

On Sun, 13 Jan 2019 21:00:28 +0000, JN wrote:
> On Sunday, 13 January 2019 at 14:47:59 UTC, Stefan Koch wrote:
>> Hi Guys,
>>
>> I've just done a small refactoring which I have been putting off for a
>> while now.
>> It should greatly help with reducing ABI bugs, and it cuts the
>> dependencies between the DMD-dependent and the independent parts of
>> newCTFE.
> 
> I'm not very familiar with the project, although I've seen the name pop up from time to time. What benefits does it provide? Is it only for DMD or will GDC/LDC make use of it too?

D's compile-time function evaluation is powerful. It's also slow and memory-hungry. newCTFE will let us run code at compile time using a more advanced interpreter, one that will be significantly faster and probably a lot gentler with memory.

On Sunday, 13 January 2019 at 14:47:59 UTC, Stefan Koch wrote:
> [ ... ]

Another small update: I've just fixed problems with class-constructor and vtbl handling.
meaning the following code does compile now.

class B {}
class C : B
{
  int _i = 2;
  int i() {return ( 1); }
}
class D : C
{
  override int i() {return 2;}
  float f() { return 1.0f; }
}
class E : D
{
  int _x;
  this(int _x)
  {
    this._x = 3;
  }
  override int i() {return _x;}
  override float f() { return 2.0f; }
}
int testClassStuff ()
{
  B b1;
  C c1, c2, c3;
  D c4;
  c1 = new C();
  c2 = new D();
  c3 = new E(3);
  b1 = new D();

  D e = new E(3);
  assert(cast(int)e.f() == 2);
  assert(c2 is c2, "Identity is broken ?");
  assert((cast(D)c3), "Dynamic cast not working");
  assert(!(cast(E)c2), "Dynamic cast not working");
  assert((cast(C)b1), "Dynamic cast not working");

  return c1.i + c2.i + c3.i;
}
static assert(testClassStuff == 1 + 2 + 3);
// the second static assert used to fail, because of stale vtbl pointers.
static assert(testClassStuff == 1 + 2 + 3);
static assert(testClassStuff == 1 + 2 + 3);

--

Cheers,

Stefan

On Sat, Jan 26, 2019 at 09:52:58PM +0000, Stefan Koch via Digitalmars-d wrote:
> On Sunday, 13 January 2019 at 14:47:59 UTC, Stefan Koch wrote:
> > [ ... ]
> 
> Another small update: I've just fixed problems with class-constructor and vtbl handling.
[...]

Good to hear progress is still happening!  Still looking forward to newCTFE landing in master, whenever that will be.


T

-- 
Never criticize a man until you've walked a mile in his shoes. Then when you do criticize him, you'll be a mile away and he won't have his shoes.

On Monday, 28 January 2019 at 17:35:12 UTC, H. S. Teoh wrote:
> On Sat, Jan 26, 2019 at 09:52:58PM +0000, Stefan Koch via Digitalmars-d wrote:
>> On Sunday, 13 January 2019 at 14:47:59 UTC, Stefan Koch wrote:
>> > [ ... ]
>> 
>> Another small update: I've just fixed problems with class-constructor and vtbl handling.
> [...]
>
> Good to hear progress is still happening!  Still looking forward to newCTFE landing in master, whenever that will be.
>
>
> T

I am proud to announce that the class-layout seems to work so far.

alias twice = long; alias once = int;
class B {once more = 0x123; twice the_fun = 0xFFF;}

class C : B
{
  int a = 12; int b = 13; int c = 14;

  final int[5] toArray()
  {
    int[5] arr;
    arr = [a, b, c, cast(int) more, cast(int) the_fun];
    return arr;
  }

}

immutable int[5] expectedData = [12, 13, 14, 0x123, 0xFFF];

auto testLayout()
{
    auto c = new C();
    // currently default ctors don't work
    // therefore we need to do this by hand
    c.a = 12; c.b = 13; c.c = 14;
    c.the_fun = 0xFFF;
    c.more = 0x123;

    return c.toArray;
}

static assert (() { return testLayout() == expectedData; } ());
// passes