[cfe-dev] CFG: scopes and destructors

[Marcin Świderski]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20100810/0579c6b3/attachment.html>