[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