[cfe-dev] [clang-tidy] scarce documentation and readability-identifier-naming

[Alexander Kornienko via cfe-dev]

On Wed, Sep 16, 2015 at 3:40 PM, Gonzalo BG <gonzalobg88 at gmail.com> wrote:

> I see, thanks for the explanation.
>
> I just started toying with clang-tidy today and while setting it up with
> CMake as a build system a verbose mode would have helped me a bit. Things
> that I would like to see are:
> - the path of the '.clang-tidy' file found,
>

Some logs to that effect are available in the assertions-enabled build when
running with -debug. But it might make sense to add some optional logging
in the release build as well.


> - if there are any unknown checks,
>

The -checks= option is a filter, not a list of checks. So there's currently
no way to tell whether there are unknown checks listed.


> - error on checks='checkA,checkB, checkC' (the whitespace error is too
> easy to make).
>

Fixed in r247812.


> I'm not finished with the setup yet since I still have some problems with
> system paths being recognized as project path and with the
> HeaderFilterRegex: '...' (I assume it does the same as -header-filter but
> that is actually not documented anywhere).
>
> I guess it would also be nice if there was a `-header-remove` option that
> takes a regex to remove some headers since mixing regexes for headers to
> accept and headers to remove inside -header-filter is messy.
>
>
> I would not need -header-remove if I would be able to get -isystem headers
> removed though. I somehow have the feeling that either clang-tidy decides
> on system headers depending on include <> vs include "" (instead of looking
> for -I or -isystem in the compilation_database.json) or just finding system
> headers in the compilation_database.json is broken.
>

The ability to  use #include <> vs #include "" depends on whether the
header can be found using -I paths or -isystem paths. If both can be used
for some headers, it seems like something that should be addressed on the
build-system (or build configuration) level to make sure code readers and
tools don't get confused.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150916/15c18f53/attachment.html>