Clangd on windows+vscode

Clang Frontend clangd
1

Hi there,

I'm trying to get clangd running inside vscode on windows. The project is using the gnu-arm-none-eabi toolchain. For almost all compilation units I get the error message "IndexingAction failed: has uncompilable errors". Is there any way to get more infos about the failure cause?

Kind regards
Michael

2

Could you try adding “-log=verbose” to clangd args? Which can be done by adding


"clangd.arguments": [
"-log=verbose",
],

to your settings.json. Then you should see the diagnostics for those uncompilable errors.

Wild guess; it will most likely be fixed with: https://reviews.llvm.org/D62804

3

Hello again,

thanks for the pointer. I was a bit puzzled by the outcome until I also added the “–synch” option in order to see that all CUs fail out of the box because the cross compiler’s paths and builtin defines are not provided. I suppose that the warnings about unsupported and thus ignored compilerflags don’t reall hurt.

I have not yet tried further adding all the paths and defines manually yet, but if I become restless, I might :wink:

It’s a shame that this is not yet supported, as the introduction of clangd rendered the cquery project abandoned, which actually supported this out of the box :frowning:

Michael

4

Hello again,

is there maybe a way to add --include directives for the clangd indexer only? I couldn’t find any command line option for this :frowning: I don’t really feel like adding around 400 defines through the commandline…

Regards
Michael

5

We don’t really have alternatives to compile_commands.json that support automatic indexing. You could use ‘compile_flags.txt’, but the auto-indexing won’t know which files it should feed into.

  • What build system do you use and how did you generate the compile_commands.json file?
  • You mentioned ccls could index your project, did it work out of the box? If it required user configuration, what was it?

Clangd relies on clang’s code to parse command line, which is mostly compatible with GCC, but I’m not sure how it handles custom GCC toolchains (and whether it handles those at all).
In general, if you manage to set up your build so that it uses clang and generate compile_commands.json from that configuration - it should work just fine.

6

Hi there,

  • I use cmake + ninja, which generates the necessary compile_commands file.
  • I mentioned cquery, which opts to query the compiler found in compile_commands for its builtins, as you can ask gcc to disclose them
  • I would prefer not to be locked into actually using clang to build the projects, and there are targets which clang does not support
  • I could live really well with clangd ignoring inline assembly and such, for which the syntax and availability of features differs between clang and gcc

Kind Regards
Michael

7

Thanks for describing the setup. Clang is generally good at mocking GCC rules for searching includes and such, but only for widely used targets (e.g. gcc targeting linux).
However, this does not seem to work as nicely for less supported toolchains (like the bare-metal arm toolchain you’re using).

+Kadir Çetinkaya is working on adding a cquery-like configuration mechanism to clangd, that should address your use-case. And in general, this seems to be a reasonable
fallback mechanism in case we hit a toolchain not well-supported by clang.
At the same time, adding better support for bare-metal arm into clang’s driver would give other benefits:

  • other clang-based tools, like clang-tidy, would work without extra configuration;
  • would allow to more closely mimic various non-include-path flags, which could also affect correctness for some corner cases;
  • allow easy switching (no extra flags needed, etc) from gcc to clang for the actual builds.

But we don’t plan to put more effort of the clangd team into the bare-metal toolchain’s driver. Hopefully someone else will improve this in the future.

8

Hi Michael, sorry for the late reply this got lost in my inbox.

We actually landed the mentioned support into clangd with https://reviews.llvm.org/D62804 you can find docs in https://clang.llvm.org/extra/clangd/Configuration.html#query-driver.
Let me know whether it works for you.

9

Hello,

I’m sorry to reply so late too, only now I have a machine capable enough to quickly build clang :wink:
The clangd experience improved much in the meanwhile and I can use it in vscode with my embedded project. That being said, clangd seems to have the builtin GCC macros hardcoded, instead of detected by the gcc toolchain. It reports GCC version 4.2 in my case, although I have a GCC 8.2.1 installed. I believe that is because of Clang.cpp:5382. This is unfortunate if you need to differ between toolchains. As this controls the default for “-fgnuc-version”, is there a way to supply that argument to clangd through the vscode plugin in addition to the stuff parsed from the compile_commands.json file? I tried mentioning it to the clangd-server, but that does not work. For now I hardcoded 8.2.1 into the clang sources. Also, would it perhaps be possible to detect and supply all the nuiltin macros from what the toolchain reports instead?

Thanks and kind regards
Michael Steinberg

10

Hi Michael,

I assume you are making use of the query-driver I suggested in my last email. Unfortunately, it doesn’t extract builtin macros as they are more hairy compared to headers.

Could you give more details about your problem, which predefined macro is causing you troubles, what does your fix in clang.cpp involve?
Most of the builtin macros are actually set when initializing the preprocessor, look for InitializePredefinedMacros in clang/lib/Frontend/InitPreprocessor.cpp.
Maybe we can come up with a generic fix in there, rather than trying to parse and redefine those macros in clangd.