[clang-tidy] Dealing with check names

I don't mind having google/llvm specific checks in list (as links).

I like the way clang-format handles this; the --style option allows
different organisations to have different default settings.

How about removing the aliases and having
--defaults={llvm,google,cert,cppcoreguidelines} select a default set of
checks and options.

I really like this idea

Malcolm Parsons

Thinking more about it I think that we should come up with some new level o
categorization of check if we would like to make this tool very easy to use.
I would like to have some kind of flag that would use some default checks,
that we know are useful for < 95% of users, have very little false
Each level (let say 4 levels like with optimizations) would have different
set of checks, where -W0 would be as good as -Wall in frontend (it would be
extended to checks that are useful but can't be in clang because analysis
would take too long). One check could be enabled in multiple levels with
different options, f.e.
modernize-loop-convert in -W0 would use MinConfidence: safe, and in -W1:
resonable and in -W3: risky.

I know that now we would have to get to consensus about which checks are
usefull on which level, but because the levels would be something that user
should not relay on, we could change the configuration every time someone
fix a bug or report a bug. And the same thing is in frontend (if warning
should go to -Wall or not) and people get to consensus what diagnostic is
good enough to be in which group.

I think that this approach ignores the behavior users are used to
seeing from diagnostics in the frontend from Clang (though this is the
approach used by other compilers, like Visual Studio). Having used
this scheme in MSVC for years, I strongly prefer the way Clang and GCC
control their diagnostics, where groupings are only for logically
related diagnostics rather than a broad categorization. I've found the
way MSVC does things to be problematic in practice; for instance, in
LLVM, we enable a specific warning level, but then have to manually
disable a dozen+ diagnostics that don't quite fit our needs.


I think it’ll be good idea to move unused checks to Clang, but will
this be easy? Clang has warnings for unused variables, static
functions and macros already. GCC has warning for unused parameters.


misc-inefficient-algorithm should be moved to performance. I tried to
do this in past, but my patch was not perfect.

misc-noexcept-move-constructor too?

Probable we should create next check groups:

Potential memory issues: