[cfe-dev] [clang-tidy] RFC: "Experimental" checkers

Dmitri Gribenko via cfe-dev cfe-dev at lists.llvm.org
Wed May 6 10:30:24 PDT 2020


I like the idea of indicating the quality/readiness of checkers somehow. It
is already the case that existing checkers have a non-uniform level of
quality despite having similar names. What's exacerbating the problem is
that it is common to enable checkers using globs based on their names --
but names don't indicate quality, only themes.

The definition of "experimental" as proposed is still fuzzy for me though.
I don't see a difference between ClangSA's:

On Wed, Mar 25, 2020 at 1:32 PM Whisperity via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

>  - the lifespan of checkers in the alpha. group is too long for Tidy's(?)
> taste
>  - alpha checkers are allowed to have crashes, lots of false positives,
> senseless output, etc.
>  - it's generally a "you're on your own" situation if you decide to run
> alpha checkers

and the proposed

> "Here's a rule, it's a nice rule, here's an automated tool for that, let's
> see what it does on live projects. This can help us develop further, or
> maybe even do rounds of revising/extending the rule/best practice itself!"

Either way, the checker might not be usable in production:

- because the false positive/negative rate is not acceptable (either
because the implementation is not good enough, or because heuristics are
not great, or because the rule needs more thought),

- because the definition of the rule might change significantly over time,
so users can't build a workflow around the rule.

I also don't see a way to ensure that an experimental checker is graduated
within a fixed time period -- apart from removing the ones that didn't make
it. That might be OK, but might also feel like an arbitrary deadline to
some contributors.


(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200506/352c9e88/attachment.html>

More information about the cfe-dev mailing list