#dbugfix 17592

Adam D. Ruppe destructionator at gmail.com
Wed Mar 21 13:55:16 UTC 2018


On Wednesday, 21 March 2018 at 08:49:11 UTC, Mike Franklin wrote:
> Step 1.  Make `emplace` @nogc
> So we need to attribute `std.conv.emplace` as @nogc.

No, do not do that! `emplace` is ALREADY `@nogc` when given 
appropriate arguments. Adding the explicit annotation will limit 
its flexibility without enabling any new uses.

This compiles right now:

---
import std.conv;

class Foo {
         this() @nogc {}
}

@nogc void main() {
         char[__traits(classInstanceSize, Foo)] buffer;
         emplace!Foo(buffer[]);
}
---


`emplace` is `@nogc` if the constructor it calls is `@nogc`.



The real bug with nogc and things like emplace are the error 
messages. They should tell you the item in the call chain where 
@nogc is NOT inferred. So if the ctor there was not annotated 
right now it says:

  Error: @nogc function D main cannot call non- at nogc function 
std.conv.emplace!(Foo).emplace

Well, it should say:

  Error: @nogc function D main cannot call non- at nogc function 
std.conv.emplace!(Foo).emplace
    >>  emplace was not inferred because it calls non- at nogc 
function `Foo.this()`


That supplemental bit with the >> indicates the ACTUAL reason 
nogc failed. Change that and the rest of the call tree becomes 
nogc automatically.

I seem to remember filing this to bugzilla sometime but bugzilla 
search is so unbelievably bad I can never find anything on there 
so idk for sure.

But this error message change would be my #1 request for nogc. 
It'd keep others from chasing false leads.


> Step 2. Make `destroy` @nogc
> `destroy` simply calls `rt_finalize` in the runtime, at least 
> for classes.  I declared it as `@nogc` in the code above, but 
> that's a cheat, though I think `rt_finalize` can be made 
> `@nogc` in the runtime.

This cannot be proven at compile time since it calls destructors 
based on a dynamic type which may or may not keep the nogc 
promise.

Of course, dtors that gc allocate are usually broken anyway... 
but it isn't a compile time guarantee in the current language and 
a library change cannot fix that alone.


More information about the Digitalmars-d mailing list