Add CI job with clang tidy
t-b opened this issue · 1 comments
t-b commented
This can already be done locally
cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=true ..
clang-tidy $(find ../cppapi -iname "*.cpp")
which gives
warnings.zip
and manually filtered
$grep "warning:" warnings.log | grep -oP "\[clang.*\]" | sort | uniq -c
18 [clang-analyzer-core.CallAndMessage]
30 [clang-analyzer-core.NonNullParamChecker]
71 [clang-analyzer-core.NullDereference]
8 [clang-analyzer-core.UndefinedBinaryOperatorResult]
4 [clang-analyzer-core.uninitialized.Assign]
12 [clang-analyzer-core.uninitialized.UndefReturn]
2 [clang-analyzer-cplusplus.NewDelete]
2 [clang-analyzer-cplusplus.NewDeleteLeaks]
26 [clang-analyzer-deadcode.DeadStores]
22 [clang-analyzer-optin.cplusplus.VirtualCall]
135 [clang-analyzer-security.insecureAPI.strcpy]
3 [clang-analyzer-unix.MismatchedDeallocator]
3 [clang-diagnostic-absolute-value]
2 [clang-diagnostic-instantiation-after-specialization]
4 [clang-diagnostic-string-plus-int]
mliszcz commented
This can already be done locally
Still I think it would be useful to consider:
- adding .clang-tidy config file with more checks enabled (especially checks related to code readability) and some other disabled (like maybe the one for non-optimal padding, which generates a lot of noise)
- running multiple tidy instances in parallel with run-clang-tidy.py script or gnu parallel or something else (related: https://reviews.llvm.org/D54141)
- ensure that we don't see duplicates coming from the same header included in multiple TUs
- ensure that warnings coming from third-party libraries are not reported.
For instance I remember seeing NullDereference reported multiple times (probably false positive) in omniORB's stringtypes.h and seqTemplatedecls.h when running clang-tidy on our attribute.cpp. I could not get rid of this neither with -line-filter
nor with -header-filter
.