[cfe-dev] [analyzer] Zombie symbols.

[Artem Dergachev via cfe-dev]

 > At which point is the symbol removed from the state? It that a
 > byproduct of the store?

Well, yeah, i guess it's probably even "the primary product" - to erase 
the original value while overwriting. And once the original value is 
erased, it's no longer referenced.

 > > 1. Scan all symbols in the SymbolManager to find zombie symbols,
 > > deprecate the maybeDead() mechanism.
 > > 2. Wait until some kind of smart data map takes care of this extra 
work.

 > Are you talking about a data structure that keeps track of the
 > data stored by the checkers. Presumably, that could be scanned
 > to find out which symbols are tracked by the checkers? This
 > direction looks the most appealing at this point.

Seems so; why i'm also thinking of "1." is because i feel it'd make 
removeDeadBindings sooo much easier to understand and sooo much more 
intuitive - which it seems to need, as even an issue as simple as this 
one had remained unnoticed. It seems that everybody was thinking that 
"1." is already there. "The garbage collector was supposed to see which 
symbols are referenced and remove those that aren't, how else could it 
work?" In this case, we probably wouldn't even need a worklist [which 
currently iterates only through the store, but also needs to iterate 
through the GDM at the same time, as there may be mutual dependencies 
between symbols here and there] during garbage collection, just rely on 
later iterations to clean up sub-symbols step by step. So i'd probably 
give it a try some day and try to explain it in more details if 
something useful shows up.

Though i've no idea about performance; the worklist would most likely 
still have better performance.

And also, if we make a new API for the data map, the old API might still 
want to be fixed somehow.