[cfe-dev] CFG: scopes and destructors

[Ted Kremenek]

On Aug 10, 2010, at 7:58 PM, Zhongxing Xu wrote:

> It is not clear where the CFGScope will fit in the original
> CFG-CFGBlock-CFGElement hierarchy. It looks like CFGScope is
> equivalent to the CFGBlock. Can we just extend CFGBlock? Whenever a
> new scope begins, we create a new CFGBlock for it. We add a 'Parent'
> member to CFGBlock and let it point to the parent block and the
> position where the scope begins.

I agree that the CFGScope doesn't fit in the CFG-CFGBlock-CFGElement hierarchy.  I actually think this scope representation has nothing to do with CFGs at all, and can be done using an entirely separate data structure.  I'll elaborate further in a direct response to Marcin's email.

Moreover, I don't think there is a one-to-one mapping between CFGBlocks and scopes.  A CFGBlock can actually contain multiple scopes.  Consider:

  {
     int x;
     {
        int y;
        {
           int z;
        }
     }
  }

All three DeclStmts go into the same CFGBlock.

> 
> Currently we don't distinguish Decls and Stmts in the CFGBlock (Decls
> are DeclStmts), because Decls may have Stmts as their initializers and
> we need to visit them along with other Stmts. But it is desired to
> improve this representation.

I'm not certain I understand what would need to be improved.  The Stmts represent what actually gets executed; DeclStmts provide a clear mapping from Decls to DeclStmts where we need to represent the "evaluation" of a Decl.

The main thing the CFG cannot represent right now (aside from destructors) are the initializers in a C++ constructor, since they aren't statements.  I think this can be done by extending CFGElement.

> 
> Destructors could be implicit in the CFG. The client can maintain a
> list of Decls which need to be destructed. An explicit list of Decls
> in each scope-beginning CFGBlock may help in this case.

I think they could be represented implicitly (from a storage perspective) in the CFG, but clients of the CFG would prefer a "view" of the CFG that makes them *look* like they are explicitly represented.  We don't want analyses having to do anything special to understand when a destructor gets called relative to all the other statements and function calls.