The check should not report includes wrapped by extern "C" { ... } blocks,
such as:
#ifdef __cplusplus extern "C" { #endif #include "assert.h" // <-- actual include #ifdef __cplusplus } #endif
This pattern comes up sometimes in header files designed to be consumed
by both C and C++ source files.
The check now reports false reports when the header file is consumed by
a C++ translation unit.
In this change, I'm not emitting the reports immediately from the
PPCallback, rather aggregating them for further processing.
After all preprocessing is done, the matcher will be called on the
TranslationUnitDecl, ensuring that the check callback is called only
once.
Within that callback, I'm recursively visiting each decls, looking for
LinkageSpecDecls which represent the extern "C" specifier.
After this, I'm dropping all the reports coming from inside of it.
After the visitation is done, I'm emitting the reports I'm left with.
The patch did not show measurable runtime difference on the following projects:
llvm-project,contour,codechecker,qtbase,protobuf,bitcoin,xerces,libwebm,tinyxml2,postgres,ffmpeg,sqlite,openssl,vim,twin,curl,tmux,memcached
So, even though the O(N * M): N includes, M extern decls might seem rough at first, it turns out to be negligible in practice.
🔮: You are storing some TU-specific state here (SourceRange) that is not cleared. What happens if you run clang-tidy a.cpp b.cpp, i.e. two TUs in the same process execution?