0

I use LLVM version 12.0.0.

Let's assume that there is library code that contains some weird code for testing purposes. This code will never be accessed during normal library use, but is only there for unit testing.

Now if a project uses that library and performs static code analysis with clang-tidy, then clang-tidy might report potential errors related to that code that is anyway considered unreachable. Please consider this minimal example:

#include <iostream>

// Code that is part of a library

class Test
{
  public:
    int number;
};

Test instance;

const Test& getMemory(bool fork)
{
    if (fork)
    {
        return instance;
    }
    else
    {
        // PROBLEM SOURCE!
        // I want to suppress all clang-tidy warnings that are related to this line, because the code will never be
        // executed. It is only there for testing purposes.
        return *(new Test);
    }
}

// Project code

int test(bool fork)
{
    // PROBLEM WARNING!
    Test myInstance = getMemory(fork);

    myInstance.number = 123;

    std::cout << "Number is " << myInstance.number << std::endl;

    return 0;
}

Adding // NOLINTNEXTLINE to the PROBLEM SOURCE position won't help. clang-tidy finds the actual misuse at the PROBLEM WARNING position. There I could add // NOLINTNEXTLINE, but I don't want to clutter my project with suppression statements for warnings that are part of a library or another project.

Also I don't want to completely suppress clang-tidy warnings related to the library. There might be valuable information for other parts of its code.

So is there a possibility to selectively suppress clang-tidy warnings related to certain code branches? It should not be a suppression of warnings for selected lines of these branches (since clang-tidy doesn't find an error there), but a suppression of warnings at other code positions that are related to these lines.

Benjamin Bihler
  • 1,612
  • 11
  • 32
  • 2
    Perhaps the project shouldn't include files that are clearly part of unit-testing, when it does static analysis of the code? Don't use wildcards like `*.h`, `*.cpp` or similar. – Some programmer dude Sep 15 '22 at 09:24
  • *"code that is anyway considered unreachable."* -- So "considered" but not "actually"? That raises a yellow flag with me. Do you have a way to detect when this assumption fails? Detect when someone decides to utilize the "weird code" for non-testing purposes? Maybe that sort of detection could be leveraged for your stated goal? – JaMiT Sep 15 '22 at 09:40
  • @Someprogrammerdude It is not about complete files, but about code branches (I tried to indicate that with the `if (fork)` branching. – Benjamin Bihler Sep 15 '22 at 09:50
  • @JaMiT Of course the code is technically reachable, otherwise it couldn't be reached during unit tests. But let's consider this to be sufficiently securely excluded by the project setup. This is exactly the purpose of warning suppressions, isn't it? - A warning is not wrong per se, but I am sure that the problem will never appear. – Benjamin Bihler Sep 15 '22 at 09:53
  • That looks like a bad design for unit-testing, mixing real and testing code. Perhaps the library authors should learn about *mocking*. You should really talk to the library authors or maintainers about that testing (anti) pattern. – Some programmer dude Sep 15 '22 at 10:00

0 Answers0