clang-tidy does not find issues for some checks in source files added with #include "some_file.cpp"

[codelimit]

Consider the following example:

lib.hpp:

#pragma once

#include <string>

namespace tidy
{
    class base
    {
    public:
        virtual ~base() = default;
        base();
        base(const base& other) = default;
        base(base&& other) = default;
        base& operator=(const base& other) = default;
        base& operator=(base&& other) = default;

    protected:
        void on_construct();
        virtual void foo() = 0;

    private:
        std::string* str = nullptr;
    };
}

lib.cpp:

#include "lib.hpp"

#include <iostream>

namespace tidy
{
    base::base()
    {
        on_construct();
    }

    void base::on_construct()
    {
        // the following check is introduced intentionally, to show that
        // clang-tidy actually examines file, finds one issue and skips other
        if (str = nullptr)
        {
            std::cout << "null\n";
        }
        foo();
    }
}

test.cpp:

#include "lib.cpp"

If I run clang-tidy lib.cpp --header-filter=.*, it finds two issues:

1. an assignment within an 'if' condition
2. Call to pure virtual method 'base::foo' during construction has undefined behavior

However if I run clang-tidy test.cpp --header-filter=.*, it finds only one:

1. an assignment within an 'if' condition

⚠️ This issue skips a lot of potential errors in a project if using cmake unity build. As most of you know, unity build increases compile time and also increase clang-tidy scan time. Having a large project (over 5k files), clang-tidy found 40 more issues when I switched off unity build.

Any hints are highly appreciated.

---

It does not depend on presence of compilation database (I intentionally skipped it), but for those who care, I add simple cmake file:
CMakeLists.txt:

cmake_minimum_required(VERSION 4.0)
project(tidy)

set(CMAKE_CXX_STANDARD 20)
set(CMAKE_CXX_EXTENSIONS OFF)
set(CMAKE_EXPORT_COMPILE_COMMANDS ON)
set(CMAKE_CXX_SCAN_FOR_MODULES OFF)

#add_library(tidy STATIC lib.cpp)
add_library(tidy STATIC test.cpp)
target_include_directories(tidy PUBLIC ${CMAKE_CURRENT_LIST_DIR})

To generate database, use
cmake -G Ninja -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -S . -B build
and then append -p build to clang-tidy cmd:
clang-tidy test.cpp --header-filter=.* -p build

I also attach the archive with sample project tidy.zip

clang-tidy version: LLVM version 21.1.4

Best regards.

[llvmbot]

@llvm/issue-subscribers-clang-tidy

Author: None (codelimit)

Consider the following example:

lib.hpp:

#pragma once

#include <string>

namespace tidy
{
    class base
    {
    public:
        virtual ~base() = default;
        base();
        base(const base& other) = default;
        base(base&& other) = default;
        base& operator=(const base& other) = default;
        base& operator=(base&& other) = default;

    protected:
        void on_construct();
        virtual void foo() = 0;

    private:
        std::string* str = nullptr;
    };
}

lib.cpp:

#include "lib.hpp"

#include <iostream>

namespace tidy
{
    base::base()
    {
        on_construct();
    }

    void base::on_construct()
    {
        if (str = nullptr)
        {
            std::cout << "null\n";
        }
        foo();
    }
}

test.cpp:

#include "lib.cpp"

If I run clang-tidy lib.cpp --header-filter=.*, it finds two issues:

1. an assignment within an 'if' condition
2. Call to pure virtual method 'base::foo' during construction has undefined behavior

However if I run clang-tidy test.cpp --header-filter=.*, it finds only one:

1. an assignment within an 'if' condition

⚠️ This issue skips a lot of potential errors in a project if using cmake unity build. As most of you know, unity build increases compile time and also increase clang-tidy scan time. Having a large project (over 5k files), clang-tidy found 40 more issues when I switched off unity build.

Any hints are highly appreciated.

---

It does not depend on presence of compilation database (I intentionally skipped it), but for those who care, I add simple cmake file:
CMakeLists.txt:

cmake_minimum_required(VERSION 4.0)
project(tidy)

set(CMAKE_CXX_STANDARD 20)
set(CMAKE_CXX_EXTENSIONS OFF)
set(CMAKE_EXPORT_COMPILE_COMMANDS ON)
set(CMAKE_CXX_SCAN_FOR_MODULES OFF)

#add_library(tidy STATIC lib.cpp)
add_library(tidy STATIC test.cpp)
target_include_directories(tidy PUBLIC ${CMAKE_CURRENT_LIST_DIR})

To generate database, use
cmake -G Ninja -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -S . -B build
and then append -p build to clang-tidy cmd:
clang-tidy test.cpp --header-filter=.* -p build

I also attach the archive with sample project tidy.zip

Best regards.

[carlosgalvezp]

Including .cpp files is not standard practice, one could even consider it as an antipattern and something to avoid. The client code should include the .hpp file, not the .cpp file.

If you are in a context with templates, and want to split the declaration from the definition in different files, then use lib.hpp and lib-impl.hpp or similar.

Would that work for you?

[codelimit]

If you are in a context with templates, and want to split the declaration from the definition in different files, then use lib.hpp and lib-impl.hpp or similar.

Would that work for you?

The sample I provided is just a minimal example to repro the issue. The actual problem is that we almost always use cmake unity build where possible. Unity build mode collects all src files for specific target, generate a cpp file and put there all the files as "#include "/abs/path/to/real_src.cpp". For example:

PS E:\work\client> cat E:\work\repo\llvm-project\llvm\cmake-build-release\tools\clang\tools\extra\clang-tidy\cppcoreguidelines\CMakeFiles\obj.clangTidyCppCoreGuidelinesModule.dir\Unity\unity_0_cxx.cxx
/* generated by CMake */

/* NOLINTNEXTLINE(bugprone-suspicious-include,misc-include-cleaner) */
#include "E:/work/repo/llvm-project/clang-tools-extra/clang-tidy/cppcoreguidelines/AvoidCapturingLambdaCoroutinesCheck.cpp"

/* NOLINTNEXTLINE(bugprone-suspicious-include,misc-include-cleaner) */
#include "E:/work/repo/llvm-project/clang-tools-extra/clang-tidy/cppcoreguidelines/AvoidConstOrRefDataMembersCheck.cpp"

/* NOLINTNEXTLINE(bugprone-suspicious-include,misc-include-cleaner) */
#include "E:/work/repo/llvm-project/clang-tools-extra/clang-tidy/cppcoreguidelines/AvoidDoWhileCheck.cpp"

/* NOLINTNEXTLINE(bugprone-suspicious-include,misc-include-cleaner) */
#include "E:/work/repo/llvm-project/clang-tools-extra/clang-tidy/cppcoreguidelines/AvoidGotoCheck.cpp"

/* NOLINTNEXTLINE(bugprone-suspicious-include,misc-include-cleaner) */
#include "E:/work/repo/llvm-project/clang-tools-extra/clang-tidy/cppcoreguidelines/AvoidNonConstGlobalVariablesCheck.cpp"

/* NOLINTNEXTLINE(bugprone-suspicious-include,misc-include-cleaner) */
#include "E:/work/repo/llvm-project/clang-tools-extra/clang-tidy/cppcoreguidelines/AvoidReferenceCoroutineParametersCheck.cpp"

/* NOLINTNEXTLINE(bugprone-suspicious-include,misc-include-cleaner) */
#include "E:/work/repo/llvm-project/clang-tools-extra/clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp"

/* NOLINTNEXTLINE(bugprone-suspicious-include,misc-include-cleaner) */
#include "E:/work/repo/llvm-project/clang-tools-extra/clang-tidy/cppcoreguidelines/InitVariablesCheck.cpp"

Therefore, clang-tidy will ignore potential errors for each project that uses cmake unity build mode.

[vbvictor]

The message Call to pure virtual method 'base::foo' during construction has undefined behavior comes from clang-analyzer-cplusplus.PureVirtualCall which is Clang Static Analyzer (CSA) check (so reference issue #166151 for more info).

My humble best guess is that CSA need a user-provided function in current TU to start building Exploded Graph and begin analysis.
In lib.cpp CSA can start from base::on_construct but test.cpp thus it has no starting point. If you write

class derived : public tidy::base {
    void foo() override {};
};

void bar() {
    derived d;
}

It starts probably from bar function and finds bug as intended.

Do you find this behavior from "real" clang-tidy checks (that doesn't start with clang-analyzer-) because I suspect this might be a CSA issue.

[llvmbot]

@llvm/issue-subscribers-clang-static-analyzer

Author: Sergey Petrovskiy (codelimit)

Consider the following example:

lib.hpp:

#pragma once

#include <string>

namespace tidy
{
    class base
    {
    public:
        virtual ~base() = default;
        base();
        base(const base& other) = default;
        base(base&& other) = default;
        base& operator=(const base& other) = default;
        base& operator=(base&& other) = default;

    protected:
        void on_construct();
        virtual void foo() = 0;

    private:
        std::string* str = nullptr;
    };
}

lib.cpp:

#include "lib.hpp"

#include <iostream>

namespace tidy
{
    base::base()
    {
        on_construct();
    }

    void base::on_construct()
    {
        // the following check is introduced intentionally, to show that
        // clang-tidy actually examines file, finds one issue and skips other
        if (str = nullptr)
        {
            std::cout << "null\n";
        }
        foo();
    }
}

test.cpp:

#include "lib.cpp"

If I run clang-tidy lib.cpp --header-filter=.*, it finds two issues:

1. an assignment within an 'if' condition
2. Call to pure virtual method 'base::foo' during construction has undefined behavior

However if I run clang-tidy test.cpp --header-filter=.*, it finds only one:

1. an assignment within an 'if' condition

⚠️ This issue skips a lot of potential errors in a project if using cmake unity build. As most of you know, unity build increases compile time and also increase clang-tidy scan time. Having a large project (over 5k files), clang-tidy found 40 more issues when I switched off unity build.

Any hints are highly appreciated.

---

It does not depend on presence of compilation database (I intentionally skipped it), but for those who care, I add simple cmake file:
CMakeLists.txt:

cmake_minimum_required(VERSION 4.0)
project(tidy)

set(CMAKE_CXX_STANDARD 20)
set(CMAKE_CXX_EXTENSIONS OFF)
set(CMAKE_EXPORT_COMPILE_COMMANDS ON)
set(CMAKE_CXX_SCAN_FOR_MODULES OFF)

#add_library(tidy STATIC lib.cpp)
add_library(tidy STATIC test.cpp)
target_include_directories(tidy PUBLIC ${CMAKE_CURRENT_LIST_DIR})

To generate database, use
cmake -G Ninja -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -S . -B build
and then append -p build to clang-tidy cmd:
clang-tidy test.cpp --header-filter=.* -p build

I also attach the archive with sample project tidy.zip

clang-tidy version: LLVM version 21.1.4

Best regards.

[codelimit]

Do you find this behavior from "real" clang-tidy checks (that doesn't start with clang-analyzer-) because I suspect this might be a CSA issue.

No, I don't see new warnings from "real" clang-tidy checks.
I've just compared two launches:

• with unity build enabled I see no warnings
• with unity build disabled I see warnings that come from clang-analyzer-* checks.

Here is a list of issues that came when I disabled unity build:
clang-analyzer-cplusplus.Move
clang-analyzer-optin.cplusplus.VirtualCall
clang-analyzer-core.DivideZero
clang-analyzer-optin.cplusplus.UninitializedObject
clang-analyzer-core.BitwiseShift
clang-analyzer-unix.Malloc
clang-analyzer-core.UndefinedBinaryOperatorResult

[codelimit]

I think I described the issue in a wrong way.

Another example.
Consider you have two files next to each other:
lib.cpp

class base
{
public:
    base() = default;
    virtual ~base() { cleanup(); }
protected:
    virtual void cleanup();
};

class derived : public base
{
public:
    derived() = default;
    ~derived() override = default;
private:
    void cleanup() override;
};

void base::cleanup() {}
void derived::cleanup() {}

test.cpp

#include "lib.cpp"

---

If I analyze lib.cpp CSA finds and reports clang-analyzer-optin.cplusplus.VirtualCall issue. clang-tidy --checks="-*,clang-analyzer-*" lib.cpp

If I analyze test.cpp CSA fails to find any issues. clang-tidy --checks="-*,clang-analyzer-*" test.cpp --header-filter='.*'

As it was already mentioned, including .cpp files is not standard practice, but this is how unity build works.

[heekinho]

I have the exact same issue, for the exact same use case (unity builds).
And you are right, abstracting it away it will just be related to including cpp files.
And also the fact that it won't respect the header filters as well (probably because CSA handles it differently).