[cfe-dev] CFGElement changes and initializers addition (with patch)

[Ted Kremenek]

On Aug 19, 2010, at 1:00 PM, Jordy Rose wrote:

>> For both destructor kinds I will need space for two pointers. For
>> automatic
>> object I need it's declaration and statement that cause destructor to be
>> called. For temporary object I need expression bound to the temporary
> and
>> the full expression that contains the temporary.
> 
> Hm. This might be true, but I'm not sure. I think the element's position
> in the CFG is good enough that we don't need "the statement that causes the
> destructor to be called". (Pseudo-destructors already count as statements
> so we don't have to worry about those.)
> 
> The temporary one is a little more worrisome, but again you might be able
> to get away with just the expression whose value is the temporary, and
> leave out the context. We certainly need to keep track of both parts when
> /building/ the CFG, but once it's complete we should be okay.

I also don't think we need to hyper optimize here.  We can burn two pointers; we just want it as svelt as possible.  The number of CFGElements is on order of the number of statements, not expressions, in a function.  If you think about the amount of data we keep track in the ASTs themsevles, burning a few extra bytes for a short-lived CFG is not really a big deal.  We just don't want it to be too bloated.

For destructors, I would like to retain enough information so that we can precisely emit good diagnostics in the static analyzer.  This includes being able to reference where the object was created and roughly where the object was destroyed.  I agree that we could possible not include the statement that causes the destructor be called *as long* as it is easy to recreate this information and vend it through a clean API to the client.