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

Valeriy Savchenko via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Thu Jun 3 08:52:02 PDT 2021


vsavchenko added a comment.

In D103605#2796425 <https://reviews.llvm.org/D103605#2796425>, @martong wrote:

> In D103605#2796141 <https://reviews.llvm.org/D103605#2796141>, @vsavchenko wrote:
>
>> In D103605#2796111 <https://reviews.llvm.org/D103605#2796111>, @martong wrote:
>>
>>> Great initiative! You haven't mention `markInteresting` functions, but I think it would be really important to incorporate that functionality here as well. IMHO, `markInteresting` shouldn't have been part of the public API ever, Checkers should have been calling only the trackExpressionValue (as internally that calls markInteresting anyway).
>>
>> Oh, yes, interesting-ness doesn't provide a very clear interface for the feedback loop that I'm trying to adjust.  From the perspective of the use "mark interesting whatever your checker is interested in and the core will figure it out", it's fine.  It has a clear message and you simply expect the engine to do its magic.  The problem comes when you try to catch something interesting from your own checker-specific visitor.  In that use case, you, first of all, really need to understand how trackers traverse the graph and what they might consider interesting, and rely on the fact that you will get the right interesting thingy.  So, the predicate checking for interesting-ness available to the users, is not very helpful IMO.
>
> What I mean is that probably we should have the following function(s) provided for the user:
>
>   Result track(SVal InterestingSVal, ....);
>   Result track(const MemRegion* InterestingRegion, ....);
>   Result track(SymbolRef InterestingSym, ....);
>
> Or even better,  only `track(SVal InterestingSVal, ....)` would be enough to be public. Then we could deprecate `markInteresting` and all Checkers should use your new Tracker interface. As I see, both trackExpressionValue and markInteresting serves the same purpose: i.e. to do a backward slicing in the ExplodedGraph to select interesing/important nodes that should be presented to the user.

We need to define semantics for those a bit better I think.  Not that `trackExpressionValue` or `FindLastStoreBRVisitor` are defined very well!  But I want to approach it incrementally and first of all make those two extendable.
But of course, whatever tracks something (want to perform backward slicing) should probably go through the tracker in the future.


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