[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


Hi,

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.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(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