[PATCH] D65723: [analyzer][NFC] Add different interestingness kinds

[Kristóf Umann via Phabricator via cfe-commits]

Szelethus created this revision.
Szelethus added reviewers: NoQ, xazax.hun, Charusso, dcoughlin, baloghadamsoftware, rnkovacs.
Szelethus added a project: clang.
Herald added subscribers: cfe-commits, gamesh411, dkrupp, donat.nagy, mikhail.ramalho, a.sidorin, szepet, whisperity.
Szelethus added parent revisions: D65575: [analyzer] Mention whether an event is about a condition in a bug report part 1, D65578: [analyzer][NFC] Make sure that the BugReport is not modified during the construction of non-visitor pieces.

We defined (on the mailing list and here on phabricator) 2 different cases where retrieving information about a control dependency condition is very important:

1. When the condition's last write happened in a different stack frame
2. When the collapse point of the condition (when we can constrain it to be true/false) didn't happen in the actual condition.

It seems like we solved this problem with the help of expression value tracking, and have started working on better diagnostics notes about this process.

Expression value tracking is nothing more than registering a variety of visitors to construct reports about it. Each of the registered visitors (`ReturnVisitor`, `FindLastStoreVisitor`, `NoStoreFuncVisitor`, etc) have //something// to go by: a `MemRegion`, an `SVal`, an `ExplodedNode`, etc. For this reason, better explaining a last write is super simple, we can always just pass on some more information to the visitor in question (as seen in D65575 <https://reviews.llvm.org/D65575>).

`ConditionBRVisitor` is a different beast, as it was built for a different purpose. It is responsible for constructing events at, well, conditions, and is registered only once, and isn't a part of the "expression value tracking family". Unfortunately, it is also //the// visitor to tinker with for constructing better diagnostics about the collapse point problem.

This creates a need for alternative way to communicate with `ConditionBRVisitor` that a specific condition is being tracked for for the reason of being a control dependency. Since at almost all `PathDiagnosticEventPiece` construction the visitor checks interestingness, it makes sense to pair interestingness with a reason as to why we marked an entity as such.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D65723

Files:
  clang/include/clang/StaticAnalyzer/Core/BugReporter/BugReporter.h
  clang/include/clang/StaticAnalyzer/Core/BugReporter/BugReporterVisitors.h
  clang/lib/StaticAnalyzer/Core/BugReporter.cpp
  clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D65723.213258.patch
Type: text/x-patch
Size: 10399 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20190804/c0829f48/attachment-0001.bin>