Help running clang-tidy via cpp-linter

[rturrado]

I have this GitHub Actions job:

name: Linters

on:
  push:
    branches:
      - develop
  pull_request:
    branches:
      - develop

jobs:
  cpp-linters:
    name: "C++ linters"
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
      - name: Run C++ linters
        uses: cpp-linter/cpp-linter-action@v2
        id: linter
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          extensions: 'cpp,hpp'
          style: 'file'  # use .clang-format config file
          tidy-checks: ''  # use .clang-tidy config file
          version: 18
      - name: Fail fast
        if: steps.linter.outputs.clang-format-checks-failed > 0
        run: |
          echo "::notice::Try executing 'python3 ./scripts/run_cpp_linters.py .' to fix linter issues."
          exit 1

I have just enabled the tidy-checks setting that variable to ''.

I have set CMAKE_EXPORT_COMPILE_COMMANDS in the outermost CMakeLists.txt:

set(CMAKE_EXPORT_COMPILE_COMMANDS ON)

clang-tidy seems to work well with the src directory but, for the test directory, it complains not being able to find some files. Although I'm not really sure what file or files caused the reported errors.

  Error: 'emscripten/bind.h' file not found
  Error: 'fmt/ostream.h' file not found
  Error: 'libqasm/tree.hpp' file not found
  Error: 'libqasm/error.hpp' file not found
  Error: 'antlr4-runtime.h' file not found
  Error: 'libqasm/v3x/parse_result.hpp' file not found
  Error: 'fmt/format.h' file not found
  Error: 'antlr4-runtime.h' file not found
  Error: 'libqasm/v3x/CqasmParser.h' file not found
  Error: 'libqasm/v3x/antlr_custom_error_listener.hpp' file not found
  Error: 'libqasm/v3x/antlr_scanner.hpp' file not found
  Error: 'libqasm/v3x/instruction_set.hpp' file not found
  Error: 'libqasm/v3x/resolver.hpp' file not found
  Error: 'libqasm/v3x/syntactic_analyzer.hpp' file not found
  Error: 'fmt/format.h' file not found
  Error: 'gmock/gmock.h' file not found
  Error: 'fmt/format.h' file not found
  Error: 'fmt/format.h' file not found

This is the GitHub Actions output.

[Question 1] Any idea how to fix these errors?

---

I have seen similar errors when running the linters locally. And I saw that, depending if I was building with gcc or clang, the compile_commands.json would be different and lead to different results when running clang-tidy.

[Question 2] Should I add a compile_commands.json file to my codebase, and provide it as an input to cpp-linter?

Many thanks!

[2bndy5]

Any idea how to fix these errors?

This question is not specific to cpp-linter.

I suspect that the generated compilation database does not include any files from the test sources. Are tests compiled as a separate target?

I see your project uses conan to drive test builds. I'm not well versed enough to investigate this. Again, this isn't an issue with cpp-linter, rather this is more of an issue with the generated database regarding test sources (& likely third-party dependencies fetched/built using conan).

[2bndy5]

Although I'm not really sure what file or files caused the reported errors.

Seems pretty clear which file/line the errors are coming from when you look at the file annotations; check that workflow's summary or the corresponding PR's diff.

[rturrado]

Beautiful, thanks. It looks it's complaining in include and src files.

[2bndy5]

Should I add a compile_commands.json file to my codebase, and provide it as an input to cpp-linter?

This is not typically done, but it is a solution if the project only uses 1 target/compiler (& C lib version).

Looking at the workflow, I don't see any command to invoke CMake for generating the compilation database before running cpp-linter. clang-tidy can't find a database that isn't there (after a clean checkout).

[rturrado]

I am not building before running the linters. Should I do it in the cpp-linters job so I have the following set up?

1. Build generates compile_commands.json.
2. cpp-linter-action uses the just generated compile_commands.json?

If so, would it matter at all for the cpp-linters-action the build type (Debug/Release) and the compiler (gcc/clang) used? Suppossing tests are built for both build types and compilers.

[2bndy5]

correct.

You'll also want to tell cpp-linter the path where the compilation database exists:

name: Linters

on:
  push:
    branches:
      - develop
  pull_request:
    branches:
      - develop

jobs:
  cpp-linters:
    name: "C++ linters"
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Generate compilation database
        # modify this command as needed
        run: cmake -B build -S src

      - name: Run C++ linters
        uses: cpp-linter/cpp-linter-action@v2
        id: linter
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          extensions: 'cpp,hpp'
          style: 'file'  # use .clang-format config file
          tidy-checks: ''  # use .clang-tidy config file
          version: 18

          database: build # compilation database exists in build folder
          ignore: build # ignore any sources copied by CMake in the build environment

      - name: Fail fast
        if: steps.linter.outputs.clang-format-checks-failed > 0
        run: |
          echo "::notice::Try executing 'python3 ./scripts/run_cpp_linters.py .' to fix linter issues."
          exit 1

I also added the ignore option because cpp-linter will try to analyze source files that are found in the build folder (which are typically copied from src by CMake).

[2bndy5]

would it matter at all for the cpp-linters-action the build type (Debug/Release) and the compiler (gcc/clang) used?

This question is only relevant regarding the compilation database. Usually, CMake will generate different compilation database contents depending on

• compiler args (which could be customized by the project's CMakeLists.txt). CMake typically tries to detect compiler features unless that option is disabled. I think this feature detection depends on the host platform.
• build types often imply different levels of optimization. I'm not sure how stripped/mangled shared binaries from third-party sources (via conan) might affect clang-tidy's behavior.

Clang-tidy may ignore some of the compiler args found in compilation database since it is not actually compiling the source code (just analyzing). The most notable compiler args that clang-tidy should respect are

• any explicit C/C++ standard (-std=c++17)
• enabled compiler warnings (-Wall)

[rturrado]

I got cpp-linters working with gcc, specifying the build folder, and ignoreing one file.

But cpp-linters fail with clang (see here). I had already seen this somewhere online. clang-tidy seems to fail to find standard files like iosfwd, memory, and so on. I'm compiling with -stdlib=libc++.

As said, maybe I shouldn't care about passing the cpp-linters with clang, as long as they pass with gcc.

[2bndy5]

Good to hear! Congrats! 🎉

But cpp-linters fail with clang (see here). I had already seen this somewhere online. clang-tidy seems to fail to find standard files like iosfwd, memory, and so on. I'm compiling with -stdlib=libc++.

You're on the right track. I think there might be discrepancy between the version of libc++ installed vs whatever version the clang compiler is using. I have little experience using the clang compiler and/or LLVM's libc++. My guess is that something needs to be specified in the CMake toolchain file that configures clang builds.

This problem used to be worse with older versions of cpp-linter. Users had reported seeing similar errors from std lib sources that were #included in the project sources (cpp-linter/cpp-linter-action#121). I'm glad to hear that cpp-linter is now only reporting these errors for project sources.

FWIW, we are installing clang-tidy/format on Linux using the LLVM's official install script (for debian based distros only). It might be possible to use this same install script to ensure the correct version of libc++ is installed as well (prior to running cpp-linter-action). For Windows runners, we use static binaries. For MacOS runners, we try to use homebrew before falling back to static binaries.