[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