C++23 and CMake

[super-betonamu-jin]

Note: All tools are from this toolkit, except clangd from official Github releases.

Inspecting the compile_commands.json generated by CMake to see why clangd doesn't work, I found:

• -fmodules-ts
• -fmodule-map-file=<path>

These are what clangd is complaining about being unknown and invalid.

More intriguing is that, even after downgrading the C++ standard to C++17 to avoid modules, clangd still doesn't work.

Neither iostream nor stdio.h are being found, which leaves me puzzled.

This issue was reported previously here: clangd/clangd#2631, but the original poster ran out of patience and left before it was resolved.

[skeeto]

There is a lack of detail here and in #385. It's not enough to say something "doesn't work". We need to know exactly what you tried and what error message you got in return. gcc -E -v looks just as I expect, and I don't know what you're seeing or what you expect to see.

Besides that, it's unclear to me if clangd is even supposed to support a situation like this. The official LLVM builds are not standalone. They require an MSVC installation, expect to interact with MSVC, do MSVC things (even with the GCC driver), and parse sources like MSVC. Looking at the logs, it seems using this particular clangd is hopeless.

llvm-mingw is more compatible, at least expecting a Mingw-w64 toolchain. Using that I got closer to something functional. I used CMAKE_EXPORT_BUILD_DATABASE to create a compile_commands.json. Then I needed to use the undocumented clangd option --resource-dir to get it to use w64dk instead of LLVM (despite --query-driver):

$ clangd --resource-dir="$W64DEVKIT_HOME" ...

However even this incorrectly guesses GCC's directory layout (missing lib/gcc/ARCH/VERSION/include), which is not special and mirrors GCC's layout on Linux. I tried to correct it with a .clangd config (CompileFlags: Add: [...]), but clangd wasn't reading it and I don't know why. So I manually added the missing -isystem to compile_commands.json and it seems like maybe it worked with --check.

[Peter0x44]

I use the clangd extension in vscode with w64devkit (pretty sure it invokes llvm-mingw) and it works just fine. Only minor issue is that it searches inside LLVM mingw's headers, not gcc's when I Ctrl+click. But it's rarely important to read c++ standard headers.

[super-betonamu-jin]

This clangd is supposed to be standalone, isn't it?

https://github.com/clangd/clangd

I'm using https://github.com/clangd/clangd/releases/download/22.1.0/clangd-windows-22.1.0.zip.

Having https://github.com/clangd/clangd/releases/download/22.1.0/clangd_indexing_tools-windows-22.1.0.zip or not doesn't make a difference.

[super-betonamu-jin]

clangd has a user-level config file named config.yaml that will take precedent over the local .clangd. I used to suspect that it was the culprit (it could very likely default to MSVC), but I can't find this file anywhere on my computer.

[super-betonamu-jin]

I used -DCMAKE_EXPORT_COMPILE_COMMANDS=ON with CMake. It doesn't add -isystem by default. There is no way to configure CMake to do so other than me manually set it in CMakeLists.txt, which I have tried.

I used premake5 compilecommands with the latest Premake5 binary in their CI. Premake5 does include -isystem by default. The generated compile_commands.json was as flawless as it could be. But none of these worked.

clangd would tell me there was duplicates in the definitions, which implied some include paths are duplicated. But I can't find any duplicated paths in the generated compile_commands.json.