bugreporter::trackNullOrUndefValue() checker API function extends a bug report with a recursive family of bug report visitors (ReturnVisitor, FindLastStoreBRVisitor, etc.) that collectively try to figure out where the given value came from. In particular, a null or undefined value, which is useful for null dereferences, uninitialized value checks, or divisions by zero. This not only improves the bug report with additional helpful diagnostic pieces, but also helps us suppress bugs that come from inlined defensive checks (the more solid potential solution for at least some of these false positives would be to introduce a state merge at call exit, but state merge is a new operation over the program states, so it would require checker side support, which is heavy).
In this patch i attempt to add more logic into the tracking, namely to be able to track a value stored in an arbitrary memory region R back to the expression that caused this value to be stored there. Previously it only worked when R is coming from a ExplodedGraph::isInterestingLValueExpression() (the exact meaning of which is "the respective node would not be reclaimed during garbage collection" (!), of course it would indeed be a shame if the node we're looking for disappears). This leaves with plain variables, member variables, and ObjC instance variables.
FindLastStoreBRVisitor is already capable of doing this in the general case of an arbitrary memory region - not only it finds the node where getSVal(R) changed, but also it finds PostStore nodes to this region even if the newly written value is same as old value.
Note that visitors are deduplicated, so we're not afraid of adding too many identical visitors.
TODO: For now i just stuffed the visitor in there, and it seems to work. But i'd like to see how much the existing code for variables can (or even must) be reused before committing, hence WIP.