[cfe-dev] [clang-tidy] Undesired diagnostics due to macro expansion from third-party headers

Dmitry Polukhin via cfe-dev cfe-dev at lists.llvm.org
Wed Jun 9 08:17:52 PDT 2021


Hi All,

I would like to know people's opinion about clang-tidy diagnostics due to
macro expansion of the macro defined in a third-party header. It is a huge
pain for clang-tidy deployment on a large codebase that actively uses
third-party bits that might not use the same clang-tidy checks enabled.
Inserting NOLINT annotation might not be a solution because in some cases
it is important to keep third-party code unmodified at all. Just one
example from a very popular gflags library. This library requires using
macro in use code like this:

DEFINE_bool(some_bool_flag,
            "the default value should go here, not the description",
            false);

But the macro has an outdated version of compiler assert that uses [C-style
arrays](
https://github.com/gflags/gflags/blob/2e227c3daae2ea8899f49858a23f3d318ea39b57/src/gflags.h.in#L528).
Therefore use code becomes incompatible with clang-tidy check
modernize-avoid-c-array. Another example of problematic is
googletest/googlemock with lots of macro that you cannot avoid.
I created RFC diff https://reviews.llvm.org/D90835 but got very limited
feedback about the proposed approach. So bringing it here to increase
visibility of the problem. Please share what you think about the problem
itself and how it should be addressed in general. Feedback about the diff
is also very appreciated but first of all I would like to understand how
you think the problem should be addressed in principle.

Thanks,
Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20210609/fe99738e/attachment.html>


More information about the cfe-dev mailing list