Hi Marcin,
One thing to keep in mind is that to support these we aren't actually adding statements or expressions (Stmt* and Expr*) to the AST, but rather elements to the CFG to represent initializers, scopes, and destructors. This will likely require extending CFGElement to represent these different concepts. For example, an initializer actually doesn't have an expression itself, although the argument to the initializer is an expression. Similarly destructor calls should probably be a special CFGElement that indicates that it is a destructor, but then references the original CallExpr that represents the constructor.
Right now a CFGElement only wraps a Stmt*, but the idea is that we could add an enum to CFGElement that makes it more general to represent other concepts.
More comments inline.
Hi Ted,
Sorry for such a late answer. I will start to work on things you mentioned about CFG.
1. Initializers:
Adding initializers should be fairly easy as there's even place marked for this. For every member and base I should add a call to appropriate constructor (if not trival?).
For the CFG for a constructor, you would need a CFGElement that modeled "calling" the constructor of the base(s) and a special CFGElement for the initializers for instance variables.
2. Scopes:
I see there's basic implementation that marks begin/end of scope based on begin/end of compound statement. If I were to extend this implementation I would:
- add end scope markers after jumps out of scope,
End scope markers probably only matter if a variable was declared within that scope. Otherwise they just add extra baggage to the CFG.
- add methods for working with scopes, e.g. check if some variable/object is in scope.
Ideally this isn't modeled at the CFG level, but in the MemRegion and LocationContext design. There we can add special LocationContexts, e.g. ScopeContext, that models a scope (and refers perhaps to the Stmt* that defines the scope). VarRegions can then have their LocationContext* be the ScopeContext* they were declared in.
3. Destructors:
Implementing destructors would involve adding statements for explicitly calling destructors at:
- for local varaibles at end of scopes,
Yes, a special CFGElement is needed for destructor calls, as I outlined above.
- in for base and members in destructor body?
Yes, this is needed as well if we want to fully model the semantics of a destructor within a CFG.
There's one thing connected with those subjects that comes to my mind: temporaries. Shouldn't we add constructors/destructors and scopes (full expressions) for those also?
We certainly need destructors (CFGElements) for temporaries, and we may need to model the constructors as well with CFGElements if they aren't explicitly represented in the AST itself.