[cfe-dev] CFG: scopes and destructors

[Ted Kremenek]

On Aug 11, 2010, at 9:07 AM, Marcin Świderski wrote:

> Hi Ted,
> 
> Thank you for this very detailed response.
> 
> CFGScope serves two purposes in what I thought of:
> 1. It describes the scope and it's relation with enclosing scope.
> 2. It allows for easy iteration through declarations (DeclStmts) we need to call destructors for.
> 

I think this is a useful concept, but as I mentioned in my email I don't think this bears any relation to the CFG data structure itself.

> Combining those two things is maybe not the best idea, so further on I will concetrate on destructors only.
> 
> What you wrote about forward traversing e.g. CompondStmt to spot all declarations we need to call destructors for was exactly what I thought of. However adding one CFGElement for each destructor call is unnecessery I think.

The advantage of explicit CFGElements is that it clearly captures where the destructor was called.  This is useful for diagnostics.  Since multiple destructors are likely to be called at once, we could collapse that information in the CFG, but that is a space optimization, and not something that should impact the CFG's interface.

> What I thought of was using data stored in CFGScope to provide list of all declarations that needs destructors to be called for them. Now I think that it would be better to use some other structure just for destructors that could be even hidden from the client.

Right.  I also don't think that using the CFGScope for this purpose would work.  The set of destructors that need to be called for a given scope varies over the scope itself as additional objects are declared.  You could possibly model this with "pseudo-scopes" layer additional scopes within a single lexical scope, each one capturing another destructor that needs to be called.

> 
> So I think that we could create CFGElement that would be placed at point, where destructors are called. It would provide, through iterators interface, list of declarations that needs destructors to be called for them.

This is reasonable, but I'd go one step further and say the the iterator interface presents distinct CFGElements for each destructor call.  How we represent it in the CFG is an implementation detail that clients should not know about.

> 
> Pros:
> 1. Less memory used (in most cases I think), because each destructor will have one entry in some list, then we will have just one CFGElement for each point where destructors are called.
> 2. Should be more robust, because less work will be done.
> 3. Easier implementation for goto statements.
> 
> Cons:
> 1. Maybe a little less intuitive interface, because having one CFGElement for each destructor call is somehow more readable.
> 
> So do you think that I can go on with my idea (for destructors only) or the one-CFGElement-for-one-desctructor-call is more desired?

There is a difference between how we represent it in the CFG itself and what interface to provide for clients.  We should not conflate how we represent the control-flow information in the CFG with how it is presented to a client of the CFG.

Clients will want an explicit view of destructor calls.  Forcing them to reconstruct the control-flow for destructors from an implicit list is highly undesirable.  There are a variety of reasons for this, but destructor calls need to compose well with the other control-flow elements in a CFG.  The job of articulating control-flow should solely be in the CFG; no client of the CFG should need to reproduce this work.

I see implicitly representing the set of destructors called at a particular point as an implementation detail of the CFG.  It could be a big efficiency win, or it may not matter.  I prefer that we do the simplest thing first, getting it working for real clients of the CFG, and then looking at how we can make it more efficient.  In the process we will likely see something that we left out of the design, and if we prematurely optimize that could just make things more painful.