clang-tidy

I have a dependency as source in my project that I have no control over. I'm using cmake's clang-tidy integration to analyze my code, and this dependency is firing A LOT of warnings. Is there a way to tell cmake not to run clang-tidy on specific files ? I tried to add the files to the -line-filter option of clang-tidy, but this doesn't work: set_target_properties(target PROPERTIES CXX_CLANG_TIDY "${clang_tidy_loc};\ ${TIDY_CONFIG} \ -line-filter=\"[\ {\"name\":\"path/to/file.cpp\"},\ {\"name\":\"path/to/file.h\"}\ ]\"") If the solution could work with other static analyzers like cppcheck it

I'd like to find out which of the clang-tidy checks are possible to run with the -fix option, i.e. automatically generate fixed code. I know all the modernize-* checks can do this and some other checks can too (like google-readability-casting) but nowhere did I find a complete list. Is there a list somewhere? Or a method to find out other than reading the source of each and every check? grep --include=\*.cpp -rc './' -e "FixItHint"|grep -v ':0$' > FixItChecks.txt I ran this grep command in the clang-tidy source directory. It counts the number of occurences of "FixItHint" string in all .cpp

I'm in the process of moving a project currently compiling with gcc to clang, and have a bunch of warnings that gcc didn't generate ( -Winconsistent-missing-override ). clang-tidy works for fixing these errors in the *.cpp files, however it doesn't touch the hpp files because a compile command wasn't found in the database (as I would expect). I'm using ninja to build the project and ninja -t compdb cc cxx > .build/compile_commands.json to generate the compilation database. I've tried running: clang-tidy-3.6 -p .build/ \ $(find src/ -name *.cpp) \ $(find src/ -name *.hpp) \ --checks=misc-use

I'm trying to use make use of clang-tidy integration with cmake and I'd like to pass the -check argument. I've tried adding -DCMAKE_CXX_CLANG_TIDY="/usr/local/opt/llvm38/bin/clang-tidy-3.8;-checks=*" when invoking cmake, but my makefile commands end-up looking like: /usr/local/Cellar/cmake/3.6.2/bin/cmake -E __run_iwyu --tidy="/usr/local/opt/llvm38/bin/clang-tidy-3.8;-checks=*" --source=/Users/ellery/work/..... in other words, it seems like the ; separated args are not being parsed apart. I've also tried setting the target property CXX_CLANG_TIDY directly on my target with the same value and I

I just installed ClangOnWin ,and I'm trying to get clang-tidy 's "modernize" checks to work. Unfortunately, clang-tidy doesn't seem to know about them: clang-tidy -list-checks foo.cpp -- | grep modernize produces no output. The "modernize" checks are listed here , but that page seems to document Clang 3.8, and the version I have installed is 3.7. However, version 3.7 is the current one listed at the LLVM Download Page . clang-tidy knows about a variety of security checks, so I think I have it installed correctly. For example, clang-tidy -list-checks foo.cpp -- | grep security yields this:

I want to use clang-tidy (LLVM v7.0.0) with the llvm-header-guard on Windows 10 with CMake for following header file #ifndef _BAR_H_ #define _BAR_H_ namespace FOO { namespace BAR { class BarC { public: BarC() = default; ~BarC() = default; BarC(const BarC &iValue) = delete; const BarC &operator=(const BarC &iValue) = delete; BarC(BarC &&iValue) = delete; BarC &operator=(BarC &&iValue) = delete; }; } // namespace BAR } // namespace FOO #endif // _BAR_H_ where the ROOT is C:\User\Zlatan\Project\Guard and the header file Bar.h is located at ROOT \Foo\Bar\src\include\Bar\Bar.h This creates

In clang tidy, the check [llvm-header-guard] looks for LLVM style header guards, but I can't find any examples of proper LLVM header guard style, specifically the structure of the name given to the define, the coding standards pages does not mention anything. Looking at the unit tests: https://github.com/llvm-mirror/clang-tools-extra/blob/master/unittests/clang-tidy/LLVMModuleTest.cpp it seems to accept a few variations on the commonly used patterns. For a file named include/llvm/ADT/foo.h the convention seems to be: #ifndef LLVM_ADT_FOO_H #define LLVM_ADT_FOO_H //... #endif // LLVM_ADT_FOO_H