CODEWITHSUNDEEP
c++boostcmakesystemclang-tidy
alfC
alfC

Reputation: 16300

Prevent clang tidy to report warnings on Boost Test headers

Note December 2022: it seems that this problem is solved in clang-tidy 14. Just by experimentation I can reproduce the problem with clang-tidy 11, 12 and 13 but not with 14.

I have a Cmake project that uses Boost.UnitTest for testing. When I do static analysis with clang-tidy it reports some warnings from the Boost.UnitTest headers. I would like to filter those.

As an example (disregard detaisl)

/usr/include/boost/test/tools/old/interface.hpp:84:45: note: expanded from macro 'BOOST_REQUIRE'
#define BOOST_REQUIRE( P )                  BOOST_TEST_TOOL_IMPL( 2, \
                                            ^
/usr/include/boost/test/tools/old/interface.hpp:65:5: note: expanded from macro 'BOOST_TEST_TOOL_IMPL'
    BOOST_TEST_PASSPOINT();                                                     \
    ^
/usr/include/boost/test/unit_test_log.hpp:261:5: note: expanded from macro 'BOOST_TEST_PASSPOINT'
    ::boost::unit_test::unit_test_log.set_checkpoint(           \
    ^
/usr/include/boost/test/unit_test_log.hpp:209:82: note: default parameter was declared here
    void                set_checkpoint( const_string file, std::size_t line_num, const_string msg = const_string() );
                                                                                 ^
/home/user/prj/alf/boost/multi/test/zero_dimensionality.cpp:23:3: error: calling a function that uses a default argument is disallowed [fuchsia-default-arguments-calls,-warnings-as-errors]
                BOOST_REQUIRE( num_elements(m1) == 3 );

So far, I add the dependency on Boost.UnitTest with these lines

    target_link_libraries(${TEST_EXE} PRIVATE Boost::unit_test_framework Boost::serialization)

I tried with this, to make Boost.UnitTest a "system" library but I still get the same warnings

    target_include_directories(${TEST_EXE} SYSTEM PRIVATE ${Boost_INCLUDE_DIRS})
    target_link_libraries(${TEST_EXE} PRIVATE ${Boost_UNIT_TEST_FRAMEWORK_LIBRARY})
    target_link_libraries(${TEST_EXE} PRIVATE ${Boost_SERIALIZATION_LIBRARY})

but I still get the same results.

How can I prevent clang-tidy to check or report errors in the Boost headers?

(I accept answers changing the configuration of clang-tidy itself (I used a .clang-tidy configuration file); although it seems more elegant to change CMakeLists.txt instead.)

ADDED NOTE:

Following one of the recommendations in the comments I disabled these warnings that were "incompatible" with Boost.Test. I would still prefer to leave them on and make clang-tidy filter somehow the headers of Boost.Test:

#  -altera-unroll-loops,                                  // BOOST_REQUIRE macro requires this
#  -cert-err58-cpp,                                       // BOOST_AUTO_TEST_CASE macro requires this
#  -cppcoreguidelines-avoid-non-const-global-variables,   // BOOST_AUTO_TEST_CASE macros require this
#  -cppcoreguidelines-macro-usage,                        // BOOST_TEST_MODULE macro requires this
#  -cppcoreguidelines-pro-type-vararg,                    // BOOST_REQUIRE macros require this
#  -fuchsia-default-arguments-declarations                // BOOST_AUTO_TEST_CASE_TEMPLATE
#  -fuchsia-default-arguments-calls,                      // BOOST_REQUIRE macros require this
#  -fuchsia-statically-constructed-objects,               // BOOST_AUTO_TEST_CASE creates these
#  -hicpp-vararg,                                         // all BOOST_TEST_REQUIRE macros require this

Upvotes: 4

Views: 1681

Answers (3)

alfC
alfC

Reputation: 16300

Solution: use clang-tidy 14 or newer.

Upvotes: -1

BeeOnRope
BeeOnRope

Reputation: 65046

If you use macros from a library which incur clang-tidy warnings, I don't think there's a good way to avoid it today. Even if you include the library as a system library (e.g., via -isystem) my understanding is the warnings will still trigger because the macro is used in your code, even if it is declared in the library.

Here's a proposal to fix it, unfortunately it seems stalled since 2021.

Upvotes: 1

sehe
sehe

Reputation: 393709

Okay, I't not entirely clear (to me) from this:

I do CXX=clang++ cmake .. -DCMAKE_CXX_CLANG_TIDY="clang-tidy" (plus a configuration file for clang-tidy)

how or when clang-tidy is actually invoked. Apparently that uses some CMake magic I'm not familiar with. I do remember once seeing such a thing, and there were reasons why I didn't end up using it.

Instead, I use CMAKE_EXPORT_COMPILE_COMMANDS=On (very handy for all tooling based on libclang and then some, like IDEs and LSP servers). Having the compile_commands.json makes it so you can invoke the run-clang-tidy tool with -p pointing to it.

In my experience it does filter system includes as it ought to (and it gives a count of diagnostics suppressed in verbose modes).

Upvotes: 1

Related Questions