[PATCH] D103605: [analyzer] Introduce a new interface for tracking

Artem Dergachev via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Fri Jun 4 13:18:07 PDT 2021


NoQ added inline comments.


================
Comment at: clang/include/clang/StaticAnalyzer/Core/BugReporter/BugReporterVisitors.h:127
+    /// into a special block region.
+    BlockCapture
+  };
----------------
xazax.hun wrote:
> There are some other places were we might have effects that are very similar to stores, like invalidations during conservative function evaluation. 
Yes, this would be really interesting.  Like, we probably don't want to add notes saying "we invalidated the Store so here's why we're now assuming stuff that seemingly contradicts our previous assumptions". But we may want to add //suppressions// based on this info, eg. "our control flow dependencies are based on invalidation, maybe let's try to find a different path to the same bug?"


================
Comment at: clang/include/clang/StaticAnalyzer/Core/BugReporter/BugReporterVisitors.h:210
+  ///        much.
+  virtual Result track(KnownSVal V, const MemRegion *R,
+                       TrackingOptions Opts = {},
----------------
xazax.hun wrote:
> Not directly related to this patch, but I wonder if we want to have unknown values with identities at some point, so we can track them.
`UnknownVal` is a stop-gap for situations when we've screwed up so badly we don't even have types anymore. The only thing I'd ever want from them is to disappear :)

I guess this could be useful for a debug checker that could explain where does an `UnknownVal` come from. In this case unknown values don't need identities; we can track other values without identities, such as null pointers, just fine.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D103605/new/

https://reviews.llvm.org/D103605



More information about the cfe-commits mailing list