Summary: Small amount of static analysis to avoid certain
                    destructor bugs
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD

--- Comment #0 from 2012-06-25 04:34:59 PDT ---
A short thread in D.learn about a core.exception.InvalidMemoryOperationError:$1707$

Caused by this code:

class X {
    string[string] s;
    this() {
        s["s"] = "S";
    ~this() {
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

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to