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
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
