A blocker for more advanced 'betterC' usage.

On Monday, 16 April 2018 at 13:01:44 UTC, Radu wrote:
> A blocker for more advanced 'betterC' usage.

https://issues.dlang.org/show_bug.cgi?id=18493

On Monday, 16 April 2018 at 13:40:55 UTC, jmh530 wrote:
> On Monday, 16 April 2018 at 13:01:44 UTC, Radu wrote:
>> A blocker for more advanced 'betterC' usage.
>
> https://issues.dlang.org/show_bug.cgi?id=18493

Noted!

On Monday, 16 April 2018 at 13:40:55 UTC, jmh530 wrote:
> On Monday, 16 April 2018 at 13:01:44 UTC, Radu wrote:
>> A blocker for more advanced 'betterC' usage.
>
> https://issues.dlang.org/show_bug.cgi?id=18493

From what I can gather this appears to be caused by a `scope(failure)` statement (https://dlang.org/spec/statement.html#scope-guard-statement) being added to the Postblit body (a.k.a. __fieldPostblit internally in the compiler).  I'm assuming `scope(failure)` is just syntactic sugar for a try-catch.

I don't know how Walter wants to handle such a situation in -betterC.  If I knew, I might be able to fix this bug.

Mike

On Tuesday, 17 April 2018 at 00:08:07 UTC, Mike Franklin wrote:
> On Monday, 16 April 2018 at 13:40:55 UTC, jmh530 wrote:
>> On Monday, 16 April 2018 at 13:01:44 UTC, Radu wrote:
>>> A blocker for more advanced 'betterC' usage.
>>
>> https://issues.dlang.org/show_bug.cgi?id=18493
>
> From what I can gather this appears to be caused by a `scope(failure)` statement (https://dlang.org/spec/statement.html#scope-guard-statement) being added to the Postblit body (a.k.a. __fieldPostblit internally in the compiler).  I'm assuming `scope(failure)` is just syntactic sugar for a try-catch.
>
> I don't know how Walter wants to handle such a situation in -betterC.  If I knew, I might be able to fix this bug.
>
> Mike

It should be a no-op under betterC because betterC implies nothrow.
It is odd though since

void foo (){}
extern(C) void main()
{
    scope(exit) foo();
}

compiles and runs with -betterC

On Tuesday, 17 April 2018 at 00:27:07 UTC, Nicholas Wilson wrote:

> It is odd though since
>
> void foo (){}
> extern(C) void main()
> {
>     scope(exit) foo();
> }
>
> compiles and runs with -betterC

I believe `scope(exit)` is fine because it is basically try-finally, but `scope(failure)` won't work because it is try-catch.

Mike

On Tuesday, 17 April 2018 at 00:08:07 UTC, Mike Franklin wrote:
> On Monday, 16 April 2018 at 13:40:55 UTC, jmh530 wrote:
>> On Monday, 16 April 2018 at 13:01:44 UTC, Radu wrote:
>>> A blocker for more advanced 'betterC' usage.
>>
>> https://issues.dlang.org/show_bug.cgi?id=18493
>
> From what I can gather this appears to be caused by a `scope(failure)` statement (https://dlang.org/spec/statement.html#scope-guard-statement) being added to the Postblit body (a.k.a. __fieldPostblit internally in the compiler).  I'm assuming `scope(failure)` is just syntactic sugar for a try-catch.
>
> I don't know how Walter wants to handle such a situation in -betterC.  If I knew, I might be able to fix this bug.
>
> Mike

This is very odd, as the following compiles:
---
struct S
{
    this(this)
    {
    }

    ~this()
    {
    }
}

struct C
{
    S s1;
}
---

If the scope failure would cause this then I assume it would not work at all in any case.

On Tuesday, 17 April 2018 at 05:33:53 UTC, Radu wrote:

> This is very odd, as the following compiles:
> ---
> struct S
> {
>     this(this)
>     {
>     }
>
>     ~this()
>     {
>     }
> }
>
> struct C
> {
>     S s1;
> }
> ---
>
> If the scope failure would cause this then I assume it would not work at all in any case.

Yeah! I think that is also a bug.  So (at least right now in my investigation) I think we first need to fix it so that it emits the error even with a single statement, and then fix it so it no longer generates the `scope(failure)` in -betterC.

Mike

On Tuesday, 17 April 2018 at 12:13:06 UTC, Mike Franklin wrote:
> On Tuesday, 17 April 2018 at 05:33:53 UTC, Radu wrote:
>
>> This is very odd, as the following compiles:
>> ---
>> struct S
>> {
>>     this(this)
>>     {
>>     }
>>
>>     ~this()
>>     {
>>     }
>> }
>>
>> struct C
>> {
>>     S s1;
>> }
>> ---
>>
>> If the scope failure would cause this then I assume it would not work at all in any case.
>
> Yeah! I think that is also a bug.  So (at least right now in my investigation) I think we first need to fix it so that it emits the error even with a single statement, and then fix it so it no longer generates the `scope(failure)` in -betterC.
>
> Mike

Making it work without `scope(failure)` in -betterC mode should be the goal of the fix, as the simple case (just one member) doesn't generate any `scope(failure)`, at least the AST ouput (https://run.dlang.io/is/l5CicG) doesn't contain it.

Thanks for looking into it!

On Tuesday, 17 April 2018 at 12:13:06 UTC, Mike Franklin wrote:
> On Tuesday, 17 April 2018 at 05:33:53 UTC, Radu wrote:
>
>> This is very odd, as the following compiles:
>> ---
>> struct S
>> {
>>     this(this)
>>     {
>>     }
>>
>>     ~this()
>>     {
>>     }
>> }
>>
>> struct C
>> {
>>     S s1;
>> }
>> ---
>>
>> If the scope failure would cause this then I assume it would not work at all in any case.
>
> Yeah! I think that is also a bug.

Nope, that's not a bug.  The reason the try-catch is only generated with two or more fields is to ensure that if an exception is thrown while blitting `s2`, `s1`'s destructor will still be called.

I'm not sure what the proper fix is yet.  The compiler could require you to attribute `this(this)` with `nothrow` in order to promise the compiler that it won't throw.  Then the compiler would know that it wouldn't need to add the try-catch around the postblit because there's no way for it to throw.  That would also ensure consistent behavior when compiling the same code with or without -betterC.

However, since throwing is off-limits entirely for -betterC, it doesn't make much sense to generate try-catch statements, only to have the compiler emit an error about it.

Maybe I should implement both. I need to sleep on it.

Mike