Thread overview | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
|
April 16, 2018 #dbugfix 18493 | ||||
---|---|---|---|---|
| ||||
A blocker for more advanced 'betterC' usage. |
April 16, 2018 Re: #dbugfix 18493 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Radu | 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 |
April 16, 2018 Re: #dbugfix 18493 | ||||
---|---|---|---|---|
| ||||
Posted in reply to jmh530 | 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!
|
April 17, 2018 Re: #dbugfix 18493 | ||||
---|---|---|---|---|
| ||||
Posted in reply to jmh530 | 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 |
April 17, 2018 Re: #dbugfix 18493 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mike Franklin | 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
|
April 17, 2018 Re: #dbugfix 18493 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nicholas Wilson | 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
|
April 17, 2018 Re: #dbugfix 18493 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mike Franklin | 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.
|
April 17, 2018 Re: #dbugfix 18493 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Radu | 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
|
April 17, 2018 Re: #dbugfix 18493 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mike Franklin | 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! |
April 17, 2018 Re: #dbugfix 18493 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mike Franklin | 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
|
Copyright © 1999-2021 by the D Language Foundation