I recently started to look into the clang-tools to enforce coding guidelines for our development group. Therefore, I played around with clang-tidy and clang-format (version 3.8 and trunk from Monday), however ran into a two problems. Before I dive deeper into the code details of both tools, I would like to check with you for known issues or hints.
1) While the compilation of the code using CMake (ninja) works fine, loading the same code via clang-tidy (and the compilation database) results in an error that a header, omp.h, could not be found. Is this a known bug for clang-tidy or might this be caused by a defect in CMake?
2) Performing a simple AST match (reduced from the clang-tidy check 'readability-identifier-naming'), that is,
fieldDecl(isPublic()).bind("public_member")
results in incorrect matches meaning that privately declared members or public type definitions of std containers like const_iterator are matched. Interestingly, I was not yet able to reproduce those errors with simplified test cases. Are there some known issues with the AST matchers that could fit my description?
Thank you for your help and support in advance,
Andi
I recently started to look into the clang-tools to enforce coding guidelines
for our development group. Therefore, I played around with clang-tidy and
clang-format (version 3.8 and trunk from Monday), however ran into a two
problems. Before I dive deeper into the code details of both tools, I would
like to check with you for known issues or hints.
1) While the compilation of the code using CMake (ninja) works fine, loading
the same code via clang-tidy (and the compilation database) results in an
error that a header, omp.h, could not be found. Is this a known bug for
clang-tidy or might this be caused by a defect in CMake?
2) Performing a simple AST match (reduced from the clang-tidy check
'readability-identifier-naming'), that is,
fieldDecl(isPublic()).bind("public_member")
results in incorrect matches meaning that privately declared members or
public type definitions of std containers like const_iterator are matched.
Interestingly, I was not yet able to reproduce those errors with simplified
test cases. Are there some known issues with the AST matchers that could fit
my description?
Do you have a code example of an incorrect match for the above matcher
that you can post? Often times, it helps to compare the matcher
results against an AST dump of the same source code to help determine
what's going on (for instance, it could be an implicit member that's
unexpectedly matching). You can do this by running clang -cc1
-ast-dump <rest of your flags> file.cpp. You can use -ast-dump-filter
to help filter unrelated results out as well.
I recently started to look into the clang-tools to enforce coding
guidelines for our development group. Therefore, I played around with
clang-tidy and clang-format (version 3.8 and trunk from Monday), however
ran into a two problems. Before I dive deeper into the code details of
both tools, I would like to check with you for known issues or hints.
While the compilation of the code using CMake (ninja) works fine,
loading the same code via clang-tidy (and the compilation database)
results in an error that a header, omp.h, could not be found. Is this a
known bug for clang-tidy or might this be caused by a defect in CMake?
This is really hard to diagnose without more info.
Performing a simple AST match (reduced from the clang-tidy check
‘readability-identifier-naming’), that is,
fieldDecl(isPublic()).bind(“public_member”)
results in incorrect matches meaning that privately declared members or
public type definitions of std containers like const_iterator are
matched. Interestingly, I was not yet able to reproduce those errors
with simplified test cases. Are there some known issues with the AST
matchers that could fit my description?
The only known issue is that it’s often hard to intuitively understand why things are in the AST. It would be great to have a smaller repro of your problem, otherwise it’s really hard to help.
thank you for your prompt reply and sorry for my belated response! Regarding the header omp.h, I meanwhile figured out that my clang-3.8 installation (from the official apt-repo) does not include the omp.h header file. If I add the omp.h from gcc, the error is gone, while others appear. But this is not your problem.
Regarding the second issue with incorrect AST matches, this is the reduced C++ code structure out of a larger C++ header file:
When I run the clang-query matcher, I get sections_ and roadLink_ as public field decls for class Road. The private members of the class before and after the class ‘Road’ are correctly matched. If I look at the ast-dump for the class Road, I see the following shortened dump:
Use clang-check to do the ast dump otherwise you have to specify the full command line. The ‘invalid’ in your dump indicates that there were parse errors, most likely due to headers that clang didn’t find.
