[cfe-dev] [analyzer] Pruning path diagnostic notes

[Artem Dergachev via cfe-dev]

(re-add cfe-dev)

On 6/23/20 8:10 AM, philip.chimento at gmail.com wrote:
> On Sun, Jun 21, 2020 at 1:57 AM Artem Dergachev <noqnoqneo at gmail.com 
> <mailto:noqnoqneo at gmail.com>> wrote:
>
>     Extra notes are annoying and potentially confusing but they're
>     technically correct so it's not too bad.
>
>
> Indeed. :-)
>
> [...]
>
>     Another example:
>
>     void f() {
>       bool bar = false;
>       if (!someResult())
>         bar = true;
>
>       int foo = 2;
>       if (bar)
>         foo = 3;
>
>       neverCallThisAPIWith3(foo);
>     }
>
>     In this case you'd want most likely want to keep the entire path
>     even though foo wasn't even declared at the first note.
>
>
> I could imagine a BugReporterVisitor that would mark 'foo' as an 
> "interesting" variable, then add itself again to mark 'bar' as 
> interesting when encountering a store to 'foo' that depends on 'bar', 
> and then another visitor that would prune notes before any 
> "interesting" points... but this is just a handwavy idea, you and 
> others have probably thought properly about this :-)

Yes, that's a fairly accurate description of the plan that we have on 
that front, and we already have that information for that particular 
example (with slight differences - say, variable 'foo' isn't interesting 
on its own, but assignment 'foo = 3' is).

There's still a lot of work to do before we're confident that we 
actually mark up all the interesting information in all cases, which is 
necessary to actually start pruning path segments. In many cases it's 
crucial to know what *hasn't* happened on the path (but *could have* 
happened if a slightly different path was taken), which is hard to mark 
up this way because there's no event to mark up because it didn't happen 
in the first place (the other path is not even necessarily explored at 
all). So for now it's better to play safe.

> Regards,
> -- 
> Philip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200624/744735d8/attachment-0001.html>