When we're tracking a variable that is responsible for a null pointer dereference or some other sinister programming error, we of course would like to gather as much information why we think that the variable has that specific value as possible. However, the newly introduced condition tracking shows that tracking all values this thoroughly could easily cause an intolerable growth in the bug report's length.
Take, for instance the following report as an example: BEFORE condition tracking, AFTER condition tracking. Having an already lengthy, bug report with 18 events grew to 45 is inexcusable.
There are a variety of heuristics we discussed on the mailing list to combat this, all of them requiring to differentiate in between tracking a "regular value" and a "condition".
This patch introduces the new bugreporter::TrackingKind enum, adds it to FindLastStoreBRVisitor as a non-optional argument, and moves some functions around to make the code a little more coherent.
What about the following?
Please consider the following example by unspoken naming conventions:
would be
where each trivial what is does, by name.
Please also note that, the thoroughness not working with redecls, assumptions, loop conditions, anything we failed to inline, etc... so it is not really that full tracking. But in our capabilities, it is the full what we could do.