[analyzer] Pruning path diagnostic notes

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[analyzer] Pruning path diagnostic notes

Vassil Vassilev via cfe-dev
Hi list,

Is there any way to get a BugReporterVisitor to delete path diagnostic notes that occur at program points that my plugin doesn't consider interesting?

For example,

void f() {
  if (!someResult())
    return;
  if (!otherResult())
    return;
  int foo = 3;
  neverCallThisAPIWith3(foo);
}

If I am checking that neverCallThisAPIWith3() is never called with 3, then in this case there are a lot of irrelevant path diagnostic notes due to the early returns. (e.g. we always see "note: Taking false branch" on the if-statements, but if we took the true branch on either of them, then we wouldn't get to the 'foo' part.) Really what I want to show in my diagnostic is notes that concern the value of variable 'foo'. If possible, I'd like to prune the notes that distinguish the path from other paths where 'foo' is never even declared.

Is this possible? I don't see any method in the docs to delete a note from a BugReport, in the first place. (Even disregarding the question of whether the criterion that I mentioned for discarding path notes is possible)

Cheers,
--
Philip C

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [analyzer] Pruning path diagnostic notes

Vassil Vassilev via cfe-dev
No, there's no API for that; you'll have to patch BugReporter from the inside to make this happen.


> Even disregarding the question of whether the criterion that I mentioned for discarding path notes is possible

This problem is not checker-specific and it's indeed a fairly hard theoretical problem in general; we have some ideas but we don't have a generic solution in mind. Extra notes are annoying and potentially confusing but they're technically correct so it's not too bad.

Say, if your code would have been slightly different:

void f() {
  int foo = 2;

  if (!someResult())
    return;

  if (otherResult())
    foo = 3;

  neverCallThisAPIWith3(foo);
}

Then you'd definitely want to keep the note about otherResult() but not probably still drop the note about someResult().

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.

On 6/21/20 6:13 AM, via cfe-dev wrote:
Hi list,

Is there any way to get a BugReporterVisitor to delete path diagnostic notes that occur at program points that my plugin doesn't consider interesting?

For example,

void f() {
  if (!someResult())
    return;
  if (!otherResult())
    return;
  int foo = 3;
  neverCallThisAPIWith3(foo);
}

If I am checking that neverCallThisAPIWith3() is never called with 3, then in this case there are a lot of irrelevant path diagnostic notes due to the early returns. (e.g. we always see "note: Taking false branch" on the if-statements, but if we took the true branch on either of them, then we wouldn't get to the 'foo' part.) Really what I want to show in my diagnostic is notes that concern the value of variable 'foo'. If possible, I'd like to prune the notes that distinguish the path from other paths where 'foo' is never even declared.

Is this possible? I don't see any method in the docs to delete a note from a BugReport, in the first place. (Even disregarding the question of whether the criterion that I mentioned for discarding path notes is possible)

Cheers,
--
Philip C

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [analyzer] Pruning path diagnostic notes

Vassil Vassilev via cfe-dev
(re-add cfe-dev)

On 6/23/20 8:10 AM, [hidden email] wrote:
On Sun, Jun 21, 2020 at 1:57 AM Artem Dergachev <[hidden email]> 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
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [analyzer] Pruning path diagnostic notes

Vassil Vassilev 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 <[hidden email]> wrote:
(re-add cfe-dev)

On 6/23/20 8:10 AM, [hidden email] wrote:
On Sun, Jun 21, 2020 at 1:57 AM Artem Dergachev <[hidden email]> 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
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev