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

[Jordy Rose]

On Wed, 18 Aug 2010 09:11:29 +0200, Marcin Świderski
<marcin.sfider at gmail.com> wrote:
> W dniu 18 sierpnia 2010 07:47 użytkownik Jordy Rose
> <jediknil at belkadan.com>napisał:
>> - I like the single enum rather than kind and subkind, but there are 7
>> elements, not 6. So it won't fit in a PointerIntPair anyway, though
>> having
>> a Stmt* field (or void*) and an enum field would be preferable to two
>> PointerIntPairs.
>> I'm still not totally convinced we need scope markers in the CFG,
though.
>>
> 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.


>> - In UnreachableCodeChecker::getUnreachableStmt(), isn't the block
>> guaranteed to have an initial statement for the same reason as in
>> ReachableCode.cpp?
>>
> Do you mean that if block is unreachable it will start with a statement
> and not with initializer, destructor or scope?

Hm, again I forget about scope. An unreachable block certainly can't start
with an initializer or destructor, but it could very well start a scope.
But this means the changes in ReachableCode.cpp have to handle this case as
well.