[PATCH] D97183: [analyzer] Add NoteTag for smart-ptr get()
Deep Majumder via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Wed Mar 17 22:29:05 PDT 2021
RedDocMD added a comment.
> Does the following test work?
@NoQ, it seems to be working.
> So you're saying that simply by always tracking the (final) raw pointer value and checking whether the raw value is interesting upon .get() you dodge the communication problem entirely
I would not say it has been dodged, but rather that problem had already been solved by `trackExpressionValue`. At line 1949 of BugReporterVisitors.cpp (inside the `trackExpressionValue` function) is:
if (LVState->getAnalysisManager().getAnalyzerOptions().ShouldTrackConditions)
report.addVisitor(std::make_unique<TrackControlDependencyCondBRVisitor>(
InputNode));
Approximately, `TrackControlDependencyCondBRVisitor` is a visitor that looks into condition statements and via mutual recursion with `trackExpressionValue` marks SVal's as interesting if they are used in a condition and that condition constrains the `Expr` on which the visitor was originally called on. This gave me the idea that calling `trackExpressionValue` is all that we really need to do, since it already contains a visitor to discover the interestingness we need. Looking into this function made me feel that `trackExpressionValue` is actually a very powerful function which solves a lot of these communication problems.
> Do i understand correctly that this doesn't happen anymore when you stopped creating a new node?
Yes, and I found out my blunder after staring at the exploded graph dump. Creating a new node was un-necessary since `trackExpressionValue` needs a node corresponding to the expression where we find the bug, and that was already being created above.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D97183/new/
https://reviews.llvm.org/D97183
More information about the cfe-commits
mailing list