Bug 8293 – Small amount of static analysis to avoid certain destructor bugs

A short thread in D.learn about a core.exception.InvalidMemoryOperationError: http://forum.dlang.org/thread/[email protected] Caused by this code: class X { string[string] s; this() { s["s"] = "S"; } ~this() { s.remove("s"); } } void main() { X x = new X(); } Jonathan M Davis: > you should never do anything in a class' destructor/finalizer which > could ever trigger the GC in any way. In past I have seen other similar bugs discussed in D.learn. I think a small amount of static analysis code added to the D front-end can statically avoid every bug of this kind. This code has to look inside ~this(){} and work recursively (like purity and nothrow enforcement do), searching for functions that perform GC activity. (This is a bit different from the enforcement of the @noheap annotation I have suggested in Issue 5219 because it's OK to manage C-heap memory inside the destructor, while @noheap looks for C-heap activity too (malloc/realloc/calloc)).

The problem is that using the gc in a destructor is perfectly valid for two reasons: - InvalidMemoryOperationError is just an implementation deficiency - You can manually call the destructor The first reason will go away eventually.

(In reply to comment #1) > - You can manually call the destructor Which more or less means that if such an object is allocated with new, there must always be a pointer to it to prevent automatic collection. Because it has to be manually destroyed to be safe. Or can the GC be improved in this regard?

(In reply to Marco Leise from comment #2) > Which more or less means that if such an object is allocated with new, there > must always be a pointer to it to prevent automatic collection. Because it > has to be manually destroyed to be safe. > Or can the GC be improved in this regard? Just use C malloc. This is what RefCounted!T does.

This should be the job of a third party tool. It's not the compiler's job to check for things like this.