[cfe-dev] clang-tidy and CppCoreGuidelines
Jonas Toth via cfe-dev
cfe-dev at lists.llvm.org
Wed Sep 27 05:37:49 PDT 2017
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>
More information about the cfe-dev
mailing list