[cfe-dev] CFG: scopes and destructors

[Zhongxing Xu]

Hi Marcin,

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.

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.

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.

2010/8/10 Marcin Świderski <marcin.sfider at gmail.com>:
> Hi,
> I'm trying to figure out how to add scopes and destructors to CFG. As I
> understand, what we need is:
> For scopes:
> - CFGElement kinds for start/end of scopes that would allow for tracking
> entering and leaving scopes.
> - If there are no variable declarations in scope, scope start/end elements
> should be omited.
> - Scope end element should be omited if there are no variable declarations
> before it in the scope.
> For destructors:
> - CFGElement kind for call to destructor.
> The main problem with implementing this in CFGBuilder is that the builder is
> processing AST backwards. When the builder have to decide if it should add a
> scope end element or a destructor it doesn't know of variables declared
> earlier in the scope. To solve this there have to be an additional step of
> walking e.g. a block of statements (compound statement) and creating a list
> of all statements declaring variables.
> Solution that I would like to propose is to make those lists a part of CFG
> instead of just temporary data used while building the graph. It would look
> something like this:
> class CFGScope {
>   Stmt* stmt; // Statement that creates the scope (e.g. CompoundStmt)
>   vector<Stmt*> decls; // Statements that declare variables in same order as
> in AST
>   CFGScopeIterator parent; // Link to position in parent scope where this
> scope started
> };
> class CFGScopeIterator {
>   CFGScope* scope; // Scope pointed by iterator
>   vector<Stmt*>::iterator pos; // Position in declarations list of the
> scope.
> };
> Now the scope start element would point to CFGScope object. The scope end
> element would point to pair (range) of CFGScopeIterators: first would point
> to position in current scope the scope end occured, second would point to
> position in some scope where the control flow did jump to. Element for
> destructors wouldn't be needed, because destructors could be easly deduced
> from range in scope end element.
> This design would allow for simple implementation of jumps out of nested
> scopes and simple modeling of destructors. Similar design could be used to
> model destructors for temporary objects.
> What do you think about this design?
> Cheers
> Sfider
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>