[cfe-dev] clang-tidy and CppCoreGuidelines

[Jonas Toth via cfe-dev]

To clarify what I would like to propose:

    Such a change would mean, that sections like `readability,
    modernize, performance, ...` still exist standalone as well as
    especially for a guideline implemented checks like
    `cppcoreguideline-owning-memory`. But when running clang-tidy to
    enforce a guideline, clang-tidy would directly activate all checks
    necessary to do so, even if there is no alias in the related module.

I think there should be 2 parallel things: '*checks*' and '*guidelines*'.

A 'guideline' is a collection of different checks and can combine 
different domains.
For example, a 'cppcoreguidelines'-guideline consists of 
`modernize-use-auto,cppcoreguidelines-owning-memory,...`. Therefor i 
think a 'guideline' is equivalent to a custom put together configuration 
file.

'checks' on the other hand remain the same, the actual code to analyze, 
diagnose and maybe fix code.

For the user the interface would be like this:
/`clang-tidy -checks=cppcoreguidelines-* # the rest` = enable all checks 
that are *directly* implemented for the cppcoreguidelines (e.g. 
owning-memory)//
//`clang-tidy -guidelines=cppcoreguideline # the rest` = enable all 
checks that are necessary to enforce the cppcoreguidelines (e.g. 
use-auto and owning-memory)//
//`clang-tidy -guidelines=hicpp,cert # the rest` = enable everything to 
ensure cert and hicpp compliance/

Given, that there are currently almost no aliases in clang-5 (only some 
of the `hicpp-*` aliases land there) we could just ignore the existing 
aliases and treat them like normal checks. There shouldn't be many 
clashes with 'guidelines' activating them.

The benefits are still:
- Aliases are ugly to handle from our side
- the source of warnings is not too obvious and it might occur that the 
warnings are once reported as `hicpp-use-auto` and `modernize-use-auto`
- bad documentation, there is no high level view (50% of the guideline 
is implemented, see here for general advice and so on) like a status page
- do not scale well. Having to maintain and keep track of potentially 
hundreds of aliases is harder for the current form

One current approximation for that approach would be custom delivered 
configuration files, that would be activated by the `-guidelines` - flag.
I would be happy to deliver these for `hicpp` and `cppcoreguidelines`, 
since i have done these pretty much already to get an overview of whats 
already implemented.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170927/309fe975/attachment.html>