An idea to avoid a narrow class of bugs

[bearophile]

I've suggested to add a little piece of static analysis inside 
the D compiler, able to catch all cases of a specific kind of 
bugs:

http://d.puremagic.com/issues/show_bug.cgi?id=8293


A short thread in D.learn about a 
core.exception.InvalidMemoryOperationError:
http://forum.dlang.org/thread/js649p$1707$1@digitalmars.com

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)).

Bye,
bearophile