Clangd headers search path on Linux #444
Comments
|
Even when I patched None of the paths include the |
|
I'm not entirely sure all what's happening here, but I have a few observations at least. When we invoke When clangd sees an invocation of This explains the difference to the Windows build of llvm-mingw; in the Windows build, we have such parameters hardcoded in the clang binary (see https://github.com/mstorsjo/llvm-mingw/blob/master/build-llvm.sh#L242-L251). However I'm not sure if this aspect explains why it thinks that things are based in I'm not very familiar with the clangd code - I assume that it should run the target specific logic for setting up include paths in See #429 (comment) for a discussion of similar issues with Another way around this would be to use config files for setting most of these parameters. I made a PoC for that many years ago, perhaps I should revisit it and see how well it would work, compared to our wrappers, at this point. |
|
Your guess is right, adding And adding the full path to the compiler executables does produce fully working system includes:
The documentation does say it uses the toolchains in It also says there is a I think it will be nice if clangd can have logic to automatically detect the compiler path in the same directory, then also have some mingw-specific logic to detect that the toolchain only ships with libc++ and automatically use that. Though I don't know if it can be added to clangd without affecting clang. Or perhaps clang could also benefit from this logic? |
|
Hmm, so to get the full picture - when you generate your I think this bit mostly is operating as expected actually. I think it's correct design that |
|
But it appears to work on Windows without the path. Why would there be a discrepancy? |
That's indeed odd. Perhaps the last-call default fallbacks differ - on Unix assuming |
|
Just to be clear, Clangd relies on heuristics on some level to find stuff (it's stated in its documentation), so it seems to me that, if the compiler driver is not found on PATH (which usually includes But I guess this ultimately needs to be discussed with Clangd developers. |
Yeah I guess that could be reasonable. But it would be interesting to dig into the code and see what it actually does and why the behaviour differs (or why it seems to find it on Windows - did you happen to have that path added when you started clangd there?) |
Nope, I never add toolchains on PATH except in the terminals I actively use to compile things. |
Another theory could be if it finds a |
Yes, this actually seems to be the case. See https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0-rc1/clang-tools-extra/clangd/CompileCommands.cpp#L88-L118 and https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0-rc1/clang-tools-extra/clangd/CompileCommands.cpp#L154-L172 |
|
As far as I my experience goes - gnu(-like) compilers will assume they should use host system paths, unless you add This is a general issue with alot clang-tooling using if you use CMake as buildsystem, using toolchain files (#430) will ensure everything works. |
The clangd binary that comes with llvm-mingw seems to not know where to look for include files. I tried with a Godot build tree that I cross-compiled using llvm-mingw, with the
compile_commands.jsongenerated by the build system available, using the Clangd extension on vscode with the path to clangd set to the one inside llvm-mingw, it isn't able to findwindows.h.Running clangd check manually:
First of all, It seems clangd thinks the compiler executable is
/usr/bin/x86_64-w64-mingw32-clang++, which does not exist. In thecompile_commands.jsonit is only listed asx86_64-w64-mingw32-clang(I only add llvm-mingw to path while building). This may not really be an issue, but I don't really know. Regardless, I was expecting clangd to be smart enough to see that these executables are right next to itself, but apparently not.Then, if we look at the list of system includes:
So it is looking for headers under
/usrfirst. I was expecting it to be smart enough to use its built-in headers first, but I guess not.More surprising is the list of "relative paths" that seem broken. I wonder why they would be included...
Running the build command manually shows the correct system includes:
Listed:
So it seems to be a clangd issue.
This does not happen on Windows when the
compile_commands.jsonalso don't include an absolute path to the compiler:The list of system includes: (
D:\gets changed toC:\d_stordue to path canonicalization, which is another thing that bothers me but let's ignore that now):If you want to reproduce this, it may be simpler to craft a
compile_commands.jsonfile manually, but the build command I used on Linux isscons -j2 dev_build=yes platform=windows use_mingw=yes use_llvm=yes target=editor.The text was updated successfully, but these errors were encountered: