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

[Gábor Horváth via cfe-dev]

I feel like this talk is slightly related to this topic:
https://www.youtube.com/watch?v=yh2qdnJjizE

Wanted to share just in case :)

On Wed, 24 Jun 2020 at 11:40, Artem Dergachev via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> (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>
> 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
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200624/691672d0/attachment.html>