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

[Kristóf Umann via cfe-dev]

>
>
> Also, we currently have 46 dependencies registered, and have a total of
> 164 checkers, meaning that a good percentage of them is affected -- would
> you say that a significant portion of these shouldn't depend on one
> another? If its not too much trouble, do you have an example on top of your
> head where you believe its appropriate, and one where its unnecessary?
>
> (You can always see the list of dependencies in <build
> directory>/tools/clang/include/clang/StaticAnalyzer/Checkers/Checkers.inc)
>
>
> I mean, let's take, say, MallocChecker. It only does modeling within its
> own isolated GDM trait; it's invisible to other families of checkers. In
> this case if the model is turned off, the checker has no effect - it
> effectively gets silently disabled, we don't need an additional facility to
> get it disabled. Most of the time we also don't need an additional facility
> to make the model enabled when the checker is enabled - because it doesn't
> make much sense to disable the model in the first place. Such dependencies
> should still be there, just for the sake of discipline and sanity (and also
> for sorting out problems with checker names), but they aren't an indication
> that our dependency trees are actually complex enough to motivate a
> facility for dependency management.
>


> On the contrary, the dependency between MoveChecker and SmartPtrModel is
> non-trivial: we made the latter specifically to fix common false positives
> of the former, so we recommend enabling the SmartPtrModel when the user
> wants MoveChecker. This is an example where things truly get complicated,
> and it will get even more complicated in the future. I think this is the
> actual motivation we have for checker dependencies and i'm very happy that
> it's in place.
>

Ah, very interesting. I actually think the contrary -- subcheckers are the
ones that really drive this dependency development forward, because for
them, its a feature, it it provides a safe, easy to use interface. Adding
more functionalities to it could further reduce boilerplate code, improve
stability and consistency.

On the other hand, MoveChecker's dependence and SmartPtrModel is far
simpler, as they don't interact at all directly. For them, the now gone
inter-checker-api header would've been sufficient as long as it gets the
job done.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190814/b5db1f7f/attachment.html>