clangd invokes the compiler driver with -x objective-c++-header which fails for GCC

[madscientist]

I am using my own install of GCC, and in order to allow the STL headers to be parsed properly I have added a .clangd file to my GCC install, that looks like this:

CompileFlags:
  Compiler: x86_64-my-gnu-g++

And I have --query-driver set to accept this compiler.

Unfortunately this fails because when clangd tries to invoke this compiler to get the compilation database (the system headers) it passes the argument -x objective-c++-header and that is obviously an invalid argument to give to GCC, so it fails:

I[16:05:33.103] Failed to find compilation database for /my/gcc/x86_64-unknown-linux-gnu/include/c++/12.3.0/condition_variable
E[16:05:33.109] System include extraction: driver execution failed with return code: 1 - ''. Args: [/my/gcc/bin/x86_64-my-gnu-g++ -E -x objective-c++-header - -v]
I[16:05:33.110] ASTWorker building file /my/gcc/x86_64-unknown-linux-gnu/include/c++/12.3.0/condition_variable version 0 with command clangd fallback
[/my/gcc/x86_64-unknown-linux-gnu/include/c++/12.3.0]
/my/gcc/bin/x86_64-my-gnu-g++ -xobjective-c++-header -resource-dir=/usr/lib/llvm-16/lib/clang/16 -- /my/gcc/x86_64-unknown-linux-gnu/include/c++/12.3.0/condition_variable

But this is not what I want: it finds the wrong version of the system headers.

It fails because this is not a valid GCC command line:

 ...
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.3.0 (GCC)
x86_64-unknown-linux-gnu-g++: error: language objective-c++-header not recognized

I can't find any way to convince clangd to use a valid language type when it invokes my compiler driver to obtain the compilation database.

System information

Output of clangd --version:
Ubuntu clangd version 16.0.6 (++20230704084246+7cbf1a259152-1~exp1~20230704204333.104)
Features: linux
Platform: x86_64-pc-linux-gnu

Editor/LSP plugin:
GNU Emacs lsp-mode

Operating system:
GNU/Linux Ubuntu 20.04 x86_64

[sam-mccall]

If you don't have a compilation database, clangd will parse "*.h" as ObjC++ by default for best parse compatibility. Indeed this interacts poorly with query-driver (using query-driver without a compilation database is a bit unusual).

If you add -xc or xc++ to the flags (through the config file, or compile_flags.txt) I think this should be passed through to the driver too.

A few other possible workarounds: add an empty compile_flags.txt to suppress the default -xobjective-c++-header, or wrap the driver in a shell script to suppress the flag, or get the paths by hand and add them to the config file directly.

[HighCommander4]

Duplicate of #1568.

I posted a proposed fix to https://reviews.llvm.org/D147905, but its discussion seems to have stalled since my last comment.

[madscientist]

By "compilation database" I'm not sure what you mean; I guess you mean compile_commands.json? I see that I've been using the wrong term: I have been calling the set of system include directories obtained from the query-driver the compilation database but that's not right.

Making the change in a wrapper is tricky to do portably, at least in POSIX sh, because I need to be sure to preserve whitespace in arguments and all that stuff. I guess I could only do this translation if invoked in the exact way clangd invokes the compiler. Adding flags directly into .clangd won't work because the compiler installation is relocatable so the root path is not static.

If you add -xc or xc++ to the flags (through the config file, or compile_flags.txt) I think this should be passed through to the driver too.

I thought I had tried this and it didn't work but now I see I made a mistake, because I was only adding flags to .h / .hpp / .hh files but these files I was testing were new-style C++ STL files that have no extension. If I simply force the Add: of -xc++ it does seem to work.

I think the change suggested in issue #1568 would be a good one to avoid the issue in the first place however.

[HighCommander4]

Closing as duplicate of #1568 which is now fixed on trunk