[PATCH] D145069: [analyzer][NFC] Split the no state change logic and bug report suppression into two visitors

[Gábor Spaits via Phabricator via cfe-commits]

spaits added a comment.

In D145069#4191046 <https://reviews.llvm.org/D145069#4191046>, @xazax.hun wrote:

> Do you plan to selectively enable warnings coming from the STL to catch misuses of certain STL types?

No. At first when we have found out that the Static Analyzer can reason about std::variant but it suppresses the diagnostics (D142354#4079643 <https://reviews.llvm.org/D142354#4079643>), we were suspecting a too strong heuristic somewhere, that invalidates even true positives. Since the Static Analyzer was able to reason about std::variant by itself we we did not want to write a checker to do the same thing. So the plan was to find the point where the suppression happen and change on the heuristics so it can let thru every kind of true positive about STL types/functions. But as it turns out, it is kind of impossible to do that without letting a lot of false positives to not be suppressed.

While it seems like it may be very difficult to unsuppress all the reports from std::variant, it still made sense to fine-tune some of these suppression.

In D145069#4191046 <https://reviews.llvm.org/D145069#4191046>, @xazax.hun wrote:

> Also, those warning reports might be leaky in a sense the reported path might contain implementations details from the STL that is hard to interpret.

We have tested the new heuristics and the new reports did not contain implementation details form STL.

In D145069#4191046 <https://reviews.llvm.org/D145069#4191046>, @xazax.hun wrote:

> I am afraid, if we want to provide a good user experience, we might be doomed to manually simulate the behavior of STL classes.

That might be the best approach to prevent the mentioned implementation dependency. Plus it would probably make it easier to write my BSc thesis if I have created a brand new checker.

On another note, it might be interesting to see how the checker approach and the force-inlining analyses compare (even if one of those approaches turn out to be a dead end).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D145069/new/

https://reviews.llvm.org/D145069