compileCommands do not work when ccache is used

[PucklaJ]

Bug type: Language Service

Describe the bug

• OS and Version: Garuda Linux
• VS Code Version: 1.56.2
• C/C++ Extension Version: 1.4.0
• Other extensions you installed (and if the issue persists after disabling them):
• If using SSH remote, specify OS of remote machine:
• A clear and concise description of what the bug is, including information about the workspace (i.e. is the workspace a single project or multiple projects, size of the project, etc).

Im am working on a C++17 project using xmake. This build system creates a compile_commands.json. If it detects ccache on the system it will use it instead of just gcc. This is also written into the compile_commands.json file. In previous versions the extension could retrieve all necessary information, but since 1.4.0 it can't and almost all types are not detected including the standard library.

Steps to reproduce

0. Either use xmake to create compile_commands.json or just create it manually including ccache
1. Create any xmake project
2. Type xmake project -k compile_commands
3. Insert path to json file into C++ settings
4. Reload window
5. See the errors

Expected behavior

All types should be detected as normal. I tried out removing all ccache entries of compile_commands.json, to see if it would work. And as I expected removing it made it work.

Code sample and logs

• Code sample

• Configurations in c_cpp_properties.json

  {
  "configurations": [
      {
          "name": "Linux",
          "compileCommands": "${workspaceFolder}/compile_commands.json"
      }
  ],
  "version": 4
  }

• compile_commands.json snippet:

  {
  "directory": "/run/media/user/Daten/Project",
  "arguments": ["/usr/bin/ccache", "/usr/bin/gcc", "-c", "-m64", "-std=c++17", "-I", "~/.xmake/packages/g/glm/0.9.9+8/65b1ad153bda4a43b0454eba7969327f/include", "-o", "build/.objs/Project/linux/x86_64/debug/src/main.cpp.o", "src/main.cpp"],
  "file": "src/main.cpp"
  },

• Logs from running C/C++: Log Diagnostics from the VS Code command palette

• Logs from the language server logging

Screenshots

Additional context

[sean-mcmanus]

Hmm, I don't see it working with 1.3.1 either -- I see it fail to query /usr/bin/ccache because the /usr/bin/gcc argument is removed. What version worked for you? UPDATE: I see it work for 1.0.1 (we changed our behavior to strip unexpected arguments in some version in between).

You may be able to workaround the issue via setting compilerPath to "/usr/bin/gcc" and compilerArgs to "["-c", "-m64", "-std=c++17", "-I", "~/.xmake/packages/g/glm/0.9.9+8/65b1ad153bda4a43b0454eba7969327f/include"].

[Colengms]

I think the issue here is that we're expecting a command line to a gcc-like compiler. The path to gcc is getting stripped out because any args that appear to refer to files (i.e. to compile) need to be removed when we probe a compiler for system includes and system defines. . We will need to find a way to handle this scenario, possibly with specific handling for ccache.

[PucklaJ]

What version worked for you?

I have been working with this extension for a long time now and up until now I never had any issues. Before automatically updating to 1.4.0 I was working with 1.3.0 and this was working fine for me.

[PucklaJ]

You may be able to workaround the issue via setting compilerPath to "/usr/bin/gcc"

Yes, this seems to fix the issue

[xclaesse]

We will need to find a way to handle this scenario, possibly with specific handling for ccache

This is still an issue, any update? I think it should be as easy as:

if args[0].endswith('ccache'):
  args = args[1:]

Note that using CC=/usr/lib/ccache/gcc works around this issue, but that's not a practical solution.

[sean-mcmanus]

Fixed with https://github.com/microsoft/vscode-cpptools/releases/tag/v1.15.2 .

[xclaesse]

@sean-mcmanus Out of curiousity, the fix is in the extension, or vscode itself? Because I did not switch the cpptools extension to pre-release but I can't reproduce the problem with ccache anymore. In any case, thanks a lot!

[sean-mcmanus]

The fix should only be in the 1.15.2 (pre-release) of our C/C++ extension and not with VS Code itself (i.e. with 1.14.5 of the C/C++ extension).

[lieser]

@sean-mcmanus Nice to see this getting fixed. I did a small test just now and unfortunately the fix in 1.15.2 only works for ccache/ccache.exe, but not if sccache/sccache.exe (https://github.com/mozilla/sccache) is used instead.

[xclaesse]

That's why my snippet above suggested args[0].endswith('ccache'), it covers sccache too. I should have pointed it out explicitly. And it also deal with /usr/lib/ccache/gcc, a simple 'ccache' in argv[0] is not good either.

[sean-mcmanus]

The sccache case is fixed with https://github.com/microsoft/vscode-cpptools/releases/tag/v1.15.3 .