<div dir="ltr"><div>Hi,</div><div><br></div><div>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.</div><div><br></div><div>The definition of "experimental" as proposed is still fuzzy for me though. I don't see a difference between ClangSA's:</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 25, 2020 at 1:32 PM Whisperity via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="ltr"> - the lifespan of checkers in the alpha. group is too long for Tidy's(?) taste<br></div><div dir="ltr"> - alpha checkers are allowed to have crashes, lots of false positives, senseless output, etc.</div><div dir="ltr"> - it's generally a "you're on your own" situation if you decide to run alpha checkers</div></div></blockquote><div><br></div><div>and the proposed</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="ltr"></div><div dir="ltr">"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!"</div></div></blockquote><div><br></div><div>Either way, the checker might not be usable in production:</div><div><br></div><div>- 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),</div><div><br></div><div>- because the definition of the rule might change significantly over time, so users can't build a workflow around the rule.</div><div><br></div><div>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.</div><div><br></div><div>Dmitri</div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature">main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if<br>(j){printf("%d\n",i);}}} /*Dmitri Gribenko <<a href="mailto:gribozavr@gmail.com" target="_blank">gribozavr@gmail.com</a>>*/</div></div>