- Sponsor
-
Notifications
You must be signed in to change notification settings - Fork 204
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
clangd struggled to find standard library headers #454
Comments
Ok, so if the same issue is present with upstream clangd, then the issue primarily isn't with llvm-mingw's packaging of clangd, but with clangd itself. The clangd in llvm-mingw has custom defaults, like defaulting to libc++ instead of libstdc++, which could make it harder to find headers in a GCC install. But if the problem exists with a default clangd as well, that's trickier. Can you, with a vanilla clangd, try executing |
This is from the official clangd:
p/s: I switched to w64devkit's GCC. |
|
Ok, I see... from the log above, It may work better if you'd set up your cmake invocation, so that it invokes Another alternative, could be if llvm-mingw would provide a clangd, which defaults to mingw mode (like it does) but without assuming the other llvm-mingw specific defaults. Can you try the same I tried doing a tweaked build of llvm-mingw, where the libc++ choice and similar isn't hardcoded, but set via config files, which may work better for cases like this. At https://github.com/mstorsjo/llvm-mingw/actions/runs/10958117646 you can find binaries from that (the binaries will be available for 7 days only). So ideally I'd like to see the |
I have the impression that clangd will always stick with the toolchain it was built for. I have used winlibs.com's mingw distro in the past. It includes Clang even though this Clang is configured to use GNU binutils and libstdc++. The performance of the clangd included in winlibs.com's distro is worse than llvm-mingw, but it also has the same problem as the clangd of llvm-mingw, that is it will only work with winlibs.com's compiler. I was unable to use it with other mingw distros, as I recall. This is the story of about two years ago. Now I don't use Windows as the development platform anymore and only build and test software on it occasionally. |
One exception might be the clangd of MSYS2 (clang-tools-extra). As I recall, it's able to work with other mingw compilers. By work, I mean getting code completion. It's too long ago and I could remember it wrong, though. |
Usual llvm-mingw:
|
windows-ucrt-x86_64-toolchain artifact:
|
So, am I reading that right, that the artifact from the test branch, which doesn't hardcode
|
The clangd of windows-ucrt-x86_64-toolchain artifact works. |
It seems you don't need to change any defaults. There is |
Oh, that looks like a neat fix for the problem! |
|
Did you try this with both the msvc clangd or the llvm-mingw one? Can you test both? And please test it with the |
Update: This worked:
This doesn't:
|
So, to get it to work you need:
|
Please see my updated comment above. You can see my |
Interesting, thanks for sharing! I guess the double backslashes in the json are for escaping purposes - does this happen to work with backslashes if you'd use only single backslashes? |
Yes. I tested and found that it also works with single backslashes path. |
Ok, that's good news, that probably clarifies the issue. Thanks for rechecking it! With these workarounds, I believe this case can be closed? If I later transition llvm-mingw to use config files, as in the linked artifacts, the issue will also end up working without the |
I'm on Windows. I originally use llvm-mingw as the default compiler, but some projects only support GCC. I finally decided to use niXman's GCC and llvm-mingw in parallel, which niXman's GCC has higher precedent in
PATH
so it will be picked up before llvm-mingw. I still use the clangd from llvm-mingw, though. The problem is even if I have acompiler_commands.json
generated by CMake, clangd still struggled to find standard library headers (of GCC). I examined thecompiler_commands.json
generated by CMake and I found it doesn't include the path to the standard library headers (why should it?). I hacked it to include the path to the standard library headers (of GCC) like the guy on #444, but it doesn't help. It will always struggled to findalgorithm
header.The same behavior with the clangd binary release provided by the clangd project on Github.
The text was updated successfully, but these errors were encountered: