www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Explaining why something isn't safe

reply Steven Schveighoffer <schveiguy gmail.com> writes:
This just came up in a discussion, and I've thought about this in the 
past, so it might have already come up. But often times, you have some 
code that you think will be ` safe`, but it gets inferred to be 
` system`. However, you can't tell where the safety violation is, so you 
have this process where you make a clone of all the code, marking 
everything as ` safe`, at all layers (even if they are in other 
projects) until you find the culprit.

As was pointed out in the discussion, the compiler knows where it 
decided to infer ` system`, would it be possible to force it to tell you 
that?

An example:

```d
void foo() {}

auto bar(int x) {
    foo();
    return x * 2;
}

void main()  safe {
    auto a = bar(5);
}
```

The result is:

```
Error: ` safe` function `D main` cannot call ` system` function `bar`
```

Whereas it would be nice to see the error:

```
Error: `bar` was inferred ` system` because it calls ` system` function 
`foo`
```

Which should go all the way down to where the actual safety problem is. 
This is a simple example that's easy to diagnose, but often times you 
have a stack of template functions, and all you get is that the top 
layer function is ` system`, instead of finding where it did the 
unexpected inference at the bottom of the stack (or you forgot to mark a 
` safe` non-inferred function).

This happens with stuff like `format` or `writeln` which is composed of 
dozens of layers of templates, and it's hard to find out which one is 
the one doing the unexpected inference. I have run across sometimes the 
inference giving up as well, which is a separate problem, but also 
useful to diagnose.

It would be nice to have a pragma (or maybe this can be a compiler 
diagnostic switch?) which shows the stack of inference that caused the 
safety error. Or maybe it should just always be shown? After all, it is 
an error, so no reason not to be fully descriptive.

-Steve
Aug 16 2021
next sibling parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Monday, 16 August 2021 at 12:51:26 UTC, Steven Schveighoffer 
wrote:

 This just came up in a discussion, and I've thought about this 
 in the past, so it might have already come up.


Forum threads are ephemeral. Add to bugzilla plz. Then it will 
never be forgotten....

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

.... or acted upon. 4 years and counting.
Aug 16 2021
next sibling parent reply bauss <jj_1337 live.dk> writes:
On Monday, 16 August 2021 at 13:05:48 UTC, Adam D Ruppe wrote:

 On Monday, 16 August 2021 at 12:51:26 UTC, Steven Schveighoffer 
 wrote:

 This just came up in a discussion, and I've thought about this 
 in the past, so it might have already come up.


 Forum threads are ephemeral. Add to bugzilla plz. Then it will 
 never be forgotten....

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

 .... or acted upon. 4 years and counting.


Damn 4 years... I think it would be a really nice addition. 
Especially for people who aren't used to  safe and I can imagine 
a lot of people just skip using it because the hassle isn't worth 
it.
Aug 16 2021
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Aug 16, 2021 at 01:29:05PM +0000, bauss via Digitalmars-d wrote:

 On Monday, 16 August 2021 at 13:05:48 UTC, Adam D Ruppe wrote:

 On Monday, 16 August 2021 at 12:51:26 UTC, Steven Schveighoffer wrote:

 This just came up in a discussion, and I've thought about this in
 the past, so it might have already come up.


 
 Forum threads are ephemeral. Add to bugzilla plz. Then it will never
 be forgotten....
 
 https://issues.dlang.org/show_bug.cgi?id=17374
 
 .... or acted upon. 4 years and counting.


 
 Damn 4 years... I think it would be a really nice addition. Especially
 for people who aren't used to  safe and I can imagine a lot of people
 just skip using it because the hassle isn't worth it.


I've been mostly ignoring  safe, and this is one of the reasons: it's
just too annoying to use sometimes.  With long UFCS chains the current
error messages just aren't helpful in finding the problem.  If this was
fixed I'd be more inclined to use  safe.


T

-- 
Not all rumours are as misleading as this one.
Aug 16 2021
prev sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 8/16/21 9:05 AM, Adam D Ruppe wrote:

 On Monday, 16 August 2021 at 12:51:26 UTC, Steven Schveighoffer wrote:

 This just came up in a discussion, and I've thought about this in the 
 past, so it might have already come up.


 
 Forum threads are ephemeral. Add to bugzilla plz. Then it will never be 
 forgotten....
 
 https://issues.dlang.org/show_bug.cgi?id=17374
 
 .... or acted upon. 4 years and counting.


Thanks, added my 2 cents there.

-Steve
Aug 16 2021
prev sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 8/16/21 8:51 AM, Steven Schveighoffer wrote:


 It would be nice to have a pragma (or maybe this can be a compiler 
 diagnostic switch?) which shows the stack of inference that caused the 
 safety error. Or maybe it should just always be shown? After all, it is 
 an error, so no reason not to be fully descriptive.


MoonlightSentinel has a [draft 
PR](https://github.com/dlang/dmd/pull/12383) that seems to cover this! 
Any chance we can get this finalized/merged? This would be an *awesome* 
addition to the compiler.

-Steve
Aug 16 2021