Can't find std headers #57

KungFuDonkey · 2022-04-15T17:48:00Z

KungFuDonkey
Apr 15, 2022

Now to my understanding not finding the standard headers is a common issue when using CLang and according to this page it is possible to remove these errors on local runs of CLang-tidy by using a script or a database. Now because this is a github action I do not know how to either generate a database for the workspace and I do not know if it is possible to check what kind of error has been thrown by the action. So maybe one of you know how to fix this.

The link to the Github action is here if you want to check out the error for yourself.

EDIT:
After a bit of digging I realised that (most likely) clang is not installed at all and thus there would be missing headers. I tried to fix this by calling a command that would install clang-14, but ubuntu said that such a package does not exist. I switched to clang-12 and installed it again, and then it said that clang was already installed. This means that if you select the clang-14 version there probably is a bug that does not install the clang package. I will make this an issue on your repo.

PS:
The rest of the action is amazing and it was really easy to set up, thank you for making this :D

Answered by 2bndy5

Apr 16, 2022

I do not know if it is possible to check what kind of error has been thrown by the action.

Well, filtering the errors thrown by clang-tidy is not an option, and it isn't a feature that we plan to add.

I do not know how to either generate a database for the workspace

This problem is rather easy. Just run CMake with the option to save the generated compilation database.

cmake -Bbuild src -DCMAKE_EXPORT_COMPILE_COMMANDS=ON

Then specify to the action where the database exists using the database option.

Full example

cpp-linter:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v2
      - name: Generate compilation database
        run: mkdir build && cmake -Bbuild src …

View full answer

2bndy5 · 2022-04-16T01:19:30Z

2bndy5
Apr 16, 2022
Maintainer

I do not know if it is possible to check what kind of error has been thrown by the action.

Well, filtering the errors thrown by clang-tidy is not an option, and it isn't a feature that we plan to add.

I do not know how to either generate a database for the workspace

This problem is rather easy. Just run CMake with the option to save the generated compilation database.

cmake -Bbuild src -DCMAKE_EXPORT_COMPILE_COMMANDS=ON

Then specify to the action where the database exists using the database option.

Full example

cpp-linter:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v2
      - name: Generate compilation database
        run: mkdir build && cmake -Bbuild src -DCMAKE_EXPORT_COMPILE_COMMANDS=ON
      - name: run linter as action
        uses: shenxianpeng/cpp-linter-action@master
        id: linter
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          files-changed-only: false
          # to ignore all build folder contents
          ignore: build
          # indicate where the database is located
          database: build
          version: 14

      - name: Fail fast?!
        if: steps.linter.outputs.checks-failed > 0
        # for actual deployment
        # run: exit 1

Clang-tidy should now be able to use the generated database and hopefully find the stddef.h.

I noticed that repo only runs CMake on a workflow that uses Windows. Unfortunately, Windows OS isn't supported for this action; it is supported by the action's src code, but the nature of using a docker image for the action limits workflow runners to Ubuntu only (per GitHub - not something we can control). This is why I design the action's src code to also be used as a python package (which should work on Windows-based workflows).

Here's an example of the action used as a python package.

      - uses: actions/setup-python@v3
      - name: Install clang-tools
        uses: KyleMayes/install-llvm-action@v1
        with:
          version: "14"

      - name: Install linter package
        run: python3 -m pip install git+https://github.com/shenxianpeng/cpp-linter-action

      - name: Generate compilation database  
        run: mkdir build && cmake -Bbuild src -DCMAKE_EXPORT_COMPILE_COMMANDS=ON

      - name: run linter as package
        id: linter
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        # --version arg is useless on Windows - it will use whatever version is installed
        # --ignore the build/* artifacts generated by CMake
        # --database indicates the path of the generated database
        run: python3 -m cpp_linter.run --ignore=build --database=build --thread-comments=true

      - name: Fail fast?!
        if: steps.linter.outputs.checks-failed > 0
        run: echo "Some files failed the linting checks!"
        # for actual deployment
        # run: exit 1

10 replies

2bndy5 Apr 16, 2022
Maintainer

It does say it is trying to create them, but nothing shows up in the Files changed tab of github.

This has to do with the path separator used in a Windows FS (\) whereas github seems to prefer the linux (& URI friendly) separator / for creating annotations. I have a fix for this on my fork (PR will be submitted when I can test it more).

Known caveat about annotating diffs

The file annotations (comments found in the event's diff - aka "Files Changed" tab) will only show the annotations made by the latest event's workflow run.

Installing a specific version of clang-tools on a windows runner requires a non-default path (to avoid the user input prompt). However, this means that our action's src code needs to be made aware of this non-default path to the executable binaries. I altered the --version arg to accept a path and use it for windows platform. Thus, the following steps work using this alteration:

  cpp-linter:
    runs-on: windows-latest

    strategy:
      matrix:
        clang-version: ['9','10', '11', '12', '13', '14']
        repo: ['2bndy5/cpp-linter-action']
        branch: ['supporting-windows-runner']
      fail-fast: false

    steps:

      - uses: actions/checkout@v3
      - uses: actions/setup-python@v3
      - name: Install clang-tools
        uses: KyleMayes/install-llvm-action@v1
        with:
          version: ${{ matrix.clang-version }}
          directory: ${{ runner.temp }}/llvm

      - name: Install linter package
        run: python3 -m pip install git+https://github.com/${{ matrix.repo }}/@${{ matrix.branch }}

      - name: Generate  compiler database  
        run: mkdir build && cmake -Bbuild src -DCMAKE_EXPORT_COMPILE_COMMANDS=ON

      - name: run linter as package
        id: linter
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: python3 -m cpp_linter.run -s=file -i=build -p=build -V=${{ runner.temp }}/llvm/bin --thread-comments=true

After I have added some code to the test project that uses #include <cstddef>, I did get an error about STL headers for clang v9, v10, & v11 (requires clang v12 or newer).

#include <cstddef>

size_t dummyFunc(size_t i) { return i; }

Obviously (because of the VS studio compiler used), this only happens when using a windows-runner. I don't get this problem on ubuntu runners using the action with its docker image.

KungFuDonkey Apr 16, 2022
Author

This has to do with the path separator used in a Windows FS () whereas github seems to prefer the linux (& URI friendly) separator / for creating annotations. I have a fix for this on my fork (PR will be submitted when I can test it more).

Okay nice, keep me posted on that as I would really like to use that.

The file annotations (comments found in the event's diff - aka "Files Changed" tab) will only show the annotations made by the latest event's workflow run.

I already noticed this, it is a really nice feature.

Installing a specific version of clang-tools on a windows runner requires a non-default path (to avoid the user input prompt). However, this means that our action's src code needs to be made aware of this non-default path to the executable binaries. I altered the --version arg to accept a path and use it for windows platform.

Okay that would indeed help with using a different version on Windows, I did not see a commit on this repo's main branch so I assume this is also on your fork?

After I have added some code to the test project that uses #include , I did get an error about STL headers for clang v9, v10, & v11 (requires clang v12 or newer).

Good to know! I was not planning on using a version lower than 11 (due to another bug in clang 10), but I will definitely avoid going to a lower version.

Thanks for al the work you are putting in I did not expect so much help from some random strangers 👍. Good to see that there are other people out there that love coding this much :D

2bndy5 Apr 16, 2022
Maintainer

I did not see a commit on this repo's main branch so I assume this is also on your fork?

Yes. All modifications aimed at better support for windows-based runners are on my fork's support-windows-runners branch. I should probably start working from this repo (not my fork) since I have the proper privileges...

Good to see that there are other people out there that love coding this much :D

❤️ I'm pretty sure my passion for open-source could be classified as an addiction 🤣

2bndy5 Apr 19, 2022
Maintainer

@KungFuDonkey Good news: My modifications for supporting windows-based runners has been merged to master. You can now find a very simple example in the README too.

KungFuDonkey Apr 19, 2022
Author

Great, thanks man! You have been super helpful and I am grateful for that. Now I can focus on finishing my bachelor, with the helpful linting tool.

shenxianpeng · 2022-04-16T10:33:20Z

shenxianpeng
Apr 16, 2022
Maintainer

Tested 13 and 14 both have 'stddef.h' file not found problem.

From the search results, it should be 13 and 14 are not properly installed into the Docker image xianpengshen/clang-tools:all so missing the following folders.

/usr/lib/llvm-13/lib
/usr/lib/llvm-14/lib

$ docker run -it -v $PWD:/src xianpengshen/clang-tools:all bash
Unable to find image 'xianpengshen/clang-tools:all' locally
all: Pulling from xianpengshen/clang-tools
4d32b49e2995: Pull complete 
1f55ef746619: Pull complete 
5949dcd7fe24: Pull complete 
Digest: sha256:ec50a7c540fa73c04423062d76c56f578958edaeea201398f77c1fbc7d28aba5
Status: Downloaded newer image for xianpengshen/clang-tools:all
root@aafbbe2227c1:/# find / -name stddef.h
find: '/proc/tty/driver': Permission denied
/usr/include/linux/stddef.h
/usr/lib/gcc/x86_64-linux-gnu/8/include/stddef.h
/usr/lib/gcc/x86_64-linux-gnu/9/include/stddef.h
/usr/lib/llvm-10/lib/clang/10.0.0/include/stddef.h
/usr/lib/llvm-11/lib/clang/11.0.0/include/stddef.h
/usr/lib/llvm-12/lib/clang/12.0.0/include/stddef.h
/usr/lib/llvm-8/lib/clang/8.0.1/include/stddef.h
/usr/lib/llvm-9/lib/clang/9.0.1/include/stddef.h

3 replies

2bndy5 Apr 16, 2022
Maintainer

Thanks for reporting this! It looks like @shenxianpeng is on the case (he's the maintainer for the docker image we use) - see cpp-linter/clang-tools-docker#25.

I've got an idea to use a matrix that will test all versions of clang-tools provided by the docker image...

shenxianpeng Apr 16, 2022
Maintainer

I have a very simple test in build-test-publish.yml ... but looking forward to your idea or PR.

2bndy5 Apr 16, 2022
Maintainer

preliminary work is in the ~~private~~ test repo's PR.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

cpp-linter

Can't find std headers #57

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Replies: 0 comments 15 replies

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Select a reply

cpp-linter

Can't find std headers #57

KungFuDonkey Apr 15, 2022

Replies: 0 comments · 15 replies

2bndy5 Apr 16, 2022 Maintainer

2bndy5 Apr 16, 2022 Maintainer

Known caveat about annotating diffs

KungFuDonkey Apr 16, 2022 Author

2bndy5 Apr 16, 2022 Maintainer

2bndy5 Apr 19, 2022 Maintainer

KungFuDonkey Apr 19, 2022 Author

shenxianpeng Apr 16, 2022 Maintainer

2bndy5 Apr 16, 2022 Maintainer

shenxianpeng Apr 16, 2022 Maintainer

2bndy5 Apr 16, 2022 Maintainer

KungFuDonkey
Apr 15, 2022

Replies: 0 comments 15 replies

2bndy5
Apr 16, 2022
Maintainer

2bndy5 Apr 16, 2022
Maintainer

KungFuDonkey Apr 16, 2022
Author

2bndy5 Apr 16, 2022
Maintainer

2bndy5 Apr 19, 2022
Maintainer

KungFuDonkey Apr 19, 2022
Author

shenxianpeng
Apr 16, 2022
Maintainer

2bndy5 Apr 16, 2022
Maintainer

shenxianpeng Apr 16, 2022
Maintainer

2bndy5 Apr 16, 2022
Maintainer