<div dir="auto"><div dir="ltr">Dear List, </div><div dir="ltr"><br></div><div dir="ltr">This is a generic interest pitch mail about adding the notion of "experimental" checks to Clang-Tidy.</div><div dir="ltr"><br></div><div dir="ltr">(A *very* rudimentary patch about the experimental group is here: <a href="http://reviews.llvm.org/D76545" rel="noreferrer noreferrer" target="_blank">http://reviews.llvm.org/D76545</a>.) </div><div dir="ltr"><br></div><div dir="ltr">The reason behind this idea is from the discussion with Aaron on a check that I developed and proposing for the suite. Review *of the check* here: <a href="http://reviews.llvm.org/D69560" rel="noreferrer noreferrer noreferrer" target="_blank">http://reviews.llvm.org/D69560</a>.</div><div dir="ltr"><br></div><div dir="ltr">Summary (of the experimental idea):</div><div dir="ltr"> - Certain rules (such as the one mentioned above) cannot (yet?) be implemented properly, due to various constraints</div><div dir="ltr"> - However, parts of the rule that *could* be implemented might turn out to be useful for the community</div><div dir="ltr"> - It's not nice to "sell" a checker named "foo-bar" if it only does "bar" partially — but coming up with a different name is superfluous as we wish to convey the intent that we support "bar" fully later on.</div><div dir="ltr"><br></div><div dir="ltr">The Clang Static Analyser people have a similar notion of "alpha.", however, several concerns about modelling that approach for Tidy has been expressed, namely:</div><div dir="ltr"> - the lifespan of checkers in the alpha. group is too long for Tidy's(?) taste</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 dir="ltr"><br></div><div dir="ltr">It's understandable that we wish to be something more stable, but this needs more input from a broader set of people.</div><div dir="ltr"><br></div><div dir="ltr">I believe that requiring stability (i.e. no crashes in general, or performance issues) from upstramed experimental checkers is a good idea. The core idea of an experimental checker could be:</div><div dir="ltr"><br></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 dir="ltr"><br></div><div dir="ltr">----</div><div dir="ltr"><br></div><div dir="ltr">First things first: main group, or subgroup?</div><div dir="ltr">We could organise the situation in two ways:</div><div dir="ltr"> - Having a top level group "experimental-<originally targeted group>-checker-name"</div><div dir="ltr"> - Or having a "subgroup" under each main group: "<originally targeted group>-experimental-checker-name"</div><div dir="ltr"><br></div><div dir="ltr">In the latter case, I believe *not* turning on experimental checks unless the user explicitly requests (in some fashion) is necessary.</div><div dir="ltr"><br></div><div dir="ltr">There're a few key bureaucracy points that need to be discussed before moving forward:</div><div dir="ltr"> </div><div dir="ltr"> 1. What's the accepted quality level for a patch to be merged as an experimental check? Where is the line between full-size checker, vs. an experimental?</div><div dir="ltr"> 2. What's the life cycle concerns involved by experimental checkers?</div><div dir="ltr"><br></div><div dir="ltr">Remember, that checkers merged into upstream will be "sold" as an LLVM feature.</div><div dir="ltr"><br></div><div dir="ltr">For 1., I think (and hopefully this is a somewhat neutral point of view argument, even though it's my patch) that the checker I'm proposing (<a href="http://reviews.llvm.org/D69560">http://reviews.llvm.org/D69560</a>) is a good example. There's a well-defined idea, and a large part of the implementation *works* in practice. (And - hopefully - there's a small amount of weird crashes here and there, I've did my best to eliminate what I could.)</div><div dir="ltr"><br></div><div dir="ltr">For 2., I'm with more lack of words. To reiterate a claim from the review of the "new group idea": In ClangSA, there are alpha checkers that had been there for years, but so far never made out of alpha, whereas requiring constant maintenance (at least to the point of making sure an internal API break is patched into them...) </div><div dir="ltr">"We don't want 'experimental-' to become a dumping ground for bad quality checks."</div><div dir="ltr"><br></div><div dir="ltr">There should be at least the general idea that we can, in the future, declare the experiment to have failed (for whatever reason, be it lack of interest, change of winds, or technical issues), and eventually deprecate and remove the related check.</div><div dir="ltr">The other path, where the experiment is a success is easier, hopefully a simple rename (and some aliasing) can solve it.</div><div dir="ltr"><br></div></div>