[PATCH] D46159: [clang-tidy] Add a flag to enable alpha checkers

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In https://reviews.llvm.org/D46159#1086627, @alexfh wrote:

> In https://reviews.llvm.org/D46159#1086493, @aaron.ballman wrote:
>
> > I think the premise is a bit off the mark. It's not that these are not for the common user -- it's that they're simply not ready for users at all. Making it easier to expose does not seem like it serves users because those users expect exposed features to work.
>
>
> That was also the sentiment static analyzer folks were voicing at some point. I also sympathize to the idea of testing checks and contributing fixes to them, but what the CSA maintainers seem to dislike is a stream of bugs for alpha checkers from users expecting of a certain level of support. So it's basically their decision whether they want to expose alpha checkers via clang frontend and/or via clang-tidy. I can only say whether I like the specific way it is done in clang-tidy.


If the static analyzer people desire this feature, that would sway my position on it, but it sounds like they're hesitant as well. However, I don't think clang-tidy is beholden either -- if we don't think this functionality should be exposed and can justify that position, that should carry weight as well. From a policy perspective, I would be fine with a policy for clang-tidy where we never expose an alpha checker from the static analyzer (or only expose checks on a case by case basis) because I don't mind users having to jump through hoops to get to experimental, unsupported functionality.

As for the way this is surfaced in clang-tidy, I'm also not keen on it but I don't have an improved suggestion to make yet. I primarily don't like the fact that, as a user, I enable checks by name but for some kinds of checks I have to *also* enable them via a secondary mechanism otherwise the name doesn't even exist. This strikes me as being a likely source of confusion where forgetting one flag causes behavioral differences the user doesn't expect.

>> Making the flag sound scary doesn't suffice -- many users never see the flags because they're hidden away in a build script, but they definitely see the diagnostics and file bug reports.
> 
> "We've fixed the glitch" by making everyone wanting a bugzilla account send an email to a human. So only the users who pass this sort of a Turing test will file bugs ;)

Which is an even worse user experience.


https://reviews.llvm.org/D46159