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

Gábor Horváth via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Fri Jun 4 12:44:51 PDT 2021


xazax.hun added inline comments.


================
Comment at: clang/include/clang/StaticAnalyzer/Core/BugReporter/BugReporterVisitors.h:110
+  /// (inlined defensive checks, returned null).
+  bool EnableNullFPSuppression = true;
+};
----------------
I vaguely remember we wanting to put this defensive check suppression in the related checkers. If that is the case, I wonder if this option belongs here. 


================
Comment at: clang/include/clang/StaticAnalyzer/Core/BugReporter/BugReporterVisitors.h:127
+    /// into a special block region.
+    BlockCapture
+  };
----------------
There are some other places were we might have effects that are very similar to stores, like invalidations during conservative function evaluation. 


================
Comment at: clang/include/clang/StaticAnalyzer/Core/BugReporter/BugReporterVisitors.h:147
+class ExpressionHandler;
+class StoreHandler;
+
----------------
During path sensitive analysis we already have a callback for stores. We kind of replicating this logic for bug paths. 
So my questions are:
* Do we expect to have additional information here that were not available during the analysis earlier?
* Do we want to make this as similar to the forward analysis part as possible for developer familiarity?


================
Comment at: clang/include/clang/StaticAnalyzer/Core/BugReporter/BugReporterVisitors.h:210
+  ///        much.
+  virtual Result track(KnownSVal V, const MemRegion *R,
+                       TrackingOptions Opts = {},
----------------
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.


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