D issues are now tracked on GitHub. This Bugzilla instance remains as a read-only archive.
Issue 20582 - destroy should be @nogc if class destructor is @nogc
Summary: destroy should be @nogc if class destructor is @nogc
Status: RESOLVED DUPLICATE of issue 15246
Alias: None
Product: D
Classification: Unclassified
Component: druntime (show other issues)
Version: D2
Hardware: All All
: P1 normal
Assignee: No Owner
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-02-15 13:27 UTC by Harry Vennik
Modified: 2020-02-15 14:27 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description Harry Vennik 2020-02-15 13:27:26 UTC
-----
class C
{
    ~this() @nogc { }
}

void foo()
{
    auto c = new C();
    () @nogc { destroy(c); } ();
}
-----

Above code snippet should compile, but doesn't:


destroy_nogc.d(9): Error: @nogc delegate destroy_nogc.foo.__lambda1 cannot call non-@nogc function object.destroy!(true, C).destroy



This also causes the following to fail:

-----
import std.experimental.allocator : make, dispose;
import std.experimental.allocator.mallocator : Mallocator;

class C
{
    ~this() @nogc { }
}

void foo() @nogc
{
    auto c = Mallocator.instance.make!C();
    Mallocator.instance.dispose(c);
}
-----

Here, dispose is inferred to be non-@nogc because it calls destroy, which is not @nogc, and thus the following error is produced:


make_dispose_nogc.d(12): Error: @nogc function make_dispose_nogc.foo cannot call non-@nogc function std.experimental.allocator.dispose!(shared(Mallocator), C).dispose

This effectively makes it impossible to write 100% @nogc code.
Comment 1 moonlightsentinel 2020-02-15 14:27:41 UTC
This is effectively caused by the way destructor chaining is implemented using rt_finalize (which iterates all destructors using RTTI). This makes static type checking for chained destructors impossible right now.
 
So even if the destructor of the current class is @nogc those found in the parent classes might not be - without checking.

*** This issue has been marked as a duplicate of issue 15246 ***