[cfe-dev] [analyzer][RFC] Our stance on checker dependencies and disabling core checkers

[Kristóf Umann via cfe-dev]

Hi!

Our stance has long been that despite being visible to the user, core
checkers shouldn't be enabled/disabled by hand, because they do important
modeling that any pathsensitive checker may depend on, potentially causing
incorrect reports and crashes. However, since then, a series of patches
gave us the ability to express dependencies and hide modeling checkers.

The core doesn't only do modeling, however, it emits diagnostics as well,
and these diagnostics may contain false positives, sometimes to the degree
where getting rid of them is desirable, yet we explicitly state that it
shouldn't be disabled. And this problem doesn't only affect the core
itself: disabling any checker that emits diagnostics and also is a
dependency of some another checker will disable dependent checkers, which
isn't always the intent.

When I originally implemented the checker dependency system, my immediate
goal was to fix a bug causing inconsistent checker names, but I firmly
believe its time to make the it even more rigid:

* Don't allow dependency checkers to emit diagnostics. Since the list of
these checkers can easily be retrieved through Checkers.td, assertions
could be used to enforce this. This would solve the issue of forgetting to
create CheckerProgramPointTags for subcheckers for good, and a helpful
assertion message could guide checker developers about it.
* Make all dependency checkers hidden. If no dependent checkers are
enabled, let the analyzer disable them. Disabling a non-hidden checker
should only mean that the diagnostics from it are undesired.
* Allow checkers to depend on packages.
* Create the hidden(!) coreModeling package, separate all the modeling from
core to it, leaving core as a set of highly recommended, but no longer
mandatory checkers. coreModeling would be a dependency of all pathsensitive
checkers.

I think this would allow users to opt out of any undesired diagnostics,
without the fear of causing instabilities. It would simultaneously create a
far more precise representation of dependencies, since no checker depends
on another's diagnostics. Also note that while this API change is
significant, its also totally backward-compatible, as nothing would change
on the user-facing side.

Would love to hear your feedback on this!

Cheers,
Kristóf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190812/594b6374/attachment.html>