[PATCH] D38171: Implement clang-tidy check aliases.

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri added a comment.

In https://reviews.llvm.org/D38171#880025, @xazax.hun wrote:

> In https://reviews.llvm.org/D38171#880022, @lebedev.ri wrote:
>
> > A mail [0] posted by @JonasToth is about the similar problem, i think we can continue there.
>
>
> Great! Could you summarize your points there as well? Thanks in advance.


Done. <https://lists.llvm.org/pipermail/cfe-dev/2017-September/055592.html>

In https://reviews.llvm.org/D38171#880024, @alexfh wrote:

> In https://reviews.llvm.org/D38171#878814, @lebedev.ri wrote:
>
> > On a somewhat related  note, since this is already talking about aliases
> >
> > I feel like the current handling of the clang-tidy check aliases needs adjusting.
> >  If one enables all the checks (`Checks: '*'`), and then disables some of them
> >  on check-by-check basis,
>
>
> Clang-tidy allows doing so, but I doubt this is a use case we want to encourage.
>  At least, not for a day-to-day use.


It's much like clang's `-Weverything`, which is rather convenient, and is
inconveniently 'missing <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31573#c2>' in gcc, because the devs believe that there would
be complains that it results in new warnings each release, 
which is kinda the point of that flag...

> Most checks require a certain amount of work on the target code and sometimes
>  fine tuning of the check options to be useful for any real codebase. Apart from that,
>  there are checks that give duplicate warnings (some are aliases and some just cover
>  intersecting set of issues), and there are checks that can give conflicting advice.
>  These facts don't combine well with the "enable almost all checks" use case and limit
>  its area of applicability to stress-testing clang-tidy and maybe to initial evaluation of
>  clang-tidy checks on a certain codebase (though going from the other direction and
>  determining the set of style rules for the codebase and then finding which of those
>  are implemented in clang-tidy is a more fruitful approach).

Except the disagreeing checks, same could be said about `-Weverything`, clang-analyzer,
etc :)   Yes, of course it does not just work, and of course needs some further tuning,
and of course the codebase that is being checked needs to be fixed not to warn.

I.e. the use-case is to always have all the warnings enabled, and each time a new check
is triggered, analyze whether it should be kept enabled, or disable it.


https://reviews.llvm.org/D38171