On Thursday, 26 January 2017 at 07:27:13 UTC, Stefan Koch wrote:
> On Wednesday, 25 January 2017 at 12:36:02 UTC, Stefan Koch wrote:
>> newCTFE is green now on all platforms!
>
> I just found an interesting bug just now.
> The following code would cause newCTFE to segfault.
>
> char* initPtr()
> {
>     return cast(char*) size_t.max;
> }
>
> static assert(cast(size_t)initPtr() == size_t.max);
>
> Because it would try to return the char-value at heap-address size_t.max;
> newCTFE allocates a 16MB heap by default and therefore the address was hopelessly out-of-bounds.
>
> The reason this was not detected before is because:
>   `cast(char*) size_t.max;`
> does not actually produce a cast expression.
> But rather an IntegerLiteral with the type char*.
>
> After dealing with dmd for 7 months, I could figure out this bug in a day.
> If I had run into this earlier I would have been stuck for weeks :)

I do not understand why it should dereference the pointer? Do you mean that the bug was that newCTFE dereferenced but it shouldn't or that oldCTFE didn't dereference but it should have?

On Thursday, 26 January 2017 at 11:59:48 UTC, Patrick Schluter wrote:
> On Thursday, 26 January 2017 at 07:27:13 UTC, Stefan Koch wrote:
>> On Wednesday, 25 January 2017 at 12:36:02 UTC, Stefan Koch wrote:
>> char* initPtr()
>> {
>>     return cast(char*) size_t.max;
>> }
>>
>> static assert(cast(size_t)initPtr() == size_t.max);
>>
>> Because it would try to return the char-value at heap-address size_t.max;
>> newCTFE allocates a 16MB heap by default and therefore the address was hopelessly out-of-bounds.
>>
>
> I do not understand why it should dereference the pointer? Do you mean that the bug was that newCTFE dereferenced but it shouldn't or that oldCTFE didn't dereference but it should have?

newCTFE should not dereference that pointer.

However since all other pointers need to be dereferenced, this bug came totally out of the blue.

Member-Function calls work now!

this code will compile and properly execute with newCTFE:

struct iota_range
{
  int current;
  int end;
  int step;

  uint front()
  {
     return current;
  }

  void popFront()
  {
    current += step;
    // we need this return otherwise we generate invalid code :(
    return ;
  }

  bool empty()
  {
    return current > end;
  }

  this(uint end, uint begin = 0, uint step = 1) pure
  {
    assert(step != 0, "cannot have a step of 0");
    this.step = step;
    this.current = begin;
    this.end = end;
  }
}

auto Iota(int end)
{
  return iota_range(end);
}

uint testThisCall(uint end)
{
  uint result;

  foreach(n;Iota(end))
  {
    result += n;
  }

  return result;
}


static assert(testThisCall(12) == 78);


Neat, huh ?

I just fixed the void initialization fail compilation tests.
By detecting the possibility of returning a void initialized field and bailing out.
dmd testsuite does now compile and pass(!) again.

I also fixed an obscure bug related to the recently introduced conecpt of heap references.

On Saturday, 28 January 2017 at 19:08:42 UTC, Stefan Koch wrote:
> I just fixed the void initialization fail compilation tests.
> By detecting the possibility of returning a void initialized field and bailing out.
> dmd testsuite does now compile and pass(!) again.
>
> I also fixed an obscure bug related to the recently introduced conecpt of heap references.

Druntime and phobos compile again and pass their respective unittests.

I also fixed a little performace bottleneck in the function-call code.
Although it is still far from optimal and can still be speed-up significantly.

However I would like to get more feature completeness before I am fixing anymore perf issues, except when they are jumping in my face :)

Also my ctfe engine still requires utf8 support, for string-foreach.
Currently there are methods for that in druntime, I hope to simply call them at ctfe, rather then re-implement them. If someone volunteers I can provide help to make them ctfeable, however at the moment my free mental bandwidth is too low to deal with utf details.

This approach will require the druntime-source containing the utf8 methods to be present and visible at every compiler run that uses string foreach.

If you consider this an issue please state why.

On Sunday, 29 January 2017 at 02:17:12 UTC, Stefan Koch wrote:
> Also my ctfe engine still requires utf8 support, for string-foreach.
> Currently there are methods for that in druntime, I hope to simply call them at ctfe, rather then re-implement them. If someone volunteers I can provide help to make them ctfeable, however at the moment my free mental bandwidth is too low to deal with utf details.
>
> This approach will require the druntime-source containing the utf8 methods to be present and visible at every compiler run that uses string foreach.
>
> If you consider this an issue please state why.

1:

I think it's good to avoid this if possible, though I'm not fiercely opposed

2:

I wrote this for mach:

https://github.com/pineapplemachine/mach.d/tree/master/mach/text/utf

If you want to borrow code or if I can provide an implementation meeting different requirements then I am at your disposal.

3:

Can you clarify what string-foreach refers to? Surely not `foreach(ch; some_string){}`, which enumerates code units and not code points?

On Sunday, 29 January 2017 at 02:46:16 UTC, pineapple wrote:
> On Sunday, 29 January 2017 at 02:17:12 UTC, Stefan Koch wrote:
>> Also my ctfe engine still requires utf8 support, for string-foreach.
>> [ ... ]

> Can you clarify what string-foreach refers to? Surely not `foreach(ch; some_string){}`, which enumerates code units and not code points?

Yes exactly that. many times in phobos foreach(dchar ch; some_string)
which requires me to encode the utf8 string temporarily into utf32
and then when it is appending to some other string I need to reencode it into utf8.

On Sunday, 29 January 2017 at 02:46:16 UTC, pineapple wrote:

> https://github.com/pineapplemachine/mach.d/tree/master/mach/text/utf
>
> If you want to borrow code or if I can provide an implementation meeting different requirements then I am at your disposal.
>

That code is a great help, understanding the issue, thanks!

On Sunday, 29 January 2017 at 02:52:51 UTC, Stefan Koch wrote:
> Yes exactly that. many times in phobos foreach(dchar ch; some_string)
> which requires me to encode the utf8 string temporarily into utf32
> and then when it is appending to some other string I need to reencode it into utf8.

Oooh, I never realized foreach acted specially like that. I can't decide whether I approve or disapprove.

You'll also have to support UTF-16 for the case `foreach(wchar ch; some_string){}`.

As before just let me know if I can help.

On 1/29/17 3:52 AM, Stefan Koch wrote:
> On Sunday, 29 January 2017 at 02:46:16 UTC, pineapple wrote:
>> On Sunday, 29 January 2017 at 02:17:12 UTC, Stefan Koch wrote:
>>> Also my ctfe engine still requires utf8 support, for string-foreach.
>>> [ ... ]
>
>> Can you clarify what string-foreach refers to? Surely not `foreach(ch;
>> some_string){}`, which enumerates code units and not code points?
>
> Yes exactly that. many times in phobos foreach(dchar ch; some_string)
> which requires me to encode the utf8 string temporarily into utf32
> and then when it is appending to some other string I need to reencode it
> into utf8.
>

Why encode the whole string to utf32? You can lower it to use std.utf.decode in a loop.

Essentially this:

foreach(dchar ch; some_string){ ... }

Becomes:

import std.utf;
size_t i=0;
while(i<some_string.length){
	dchar ch = decode(some_string, i);
	...
}

---
Dmitry Olshansky