Eclipse indexer unable to find std or the first C++ include in files

[mbratch]

I am running Eclipse version 2023-09 (4.29.0) and have the Espressif ESP-IDF plugin version 2.11.1.202310270725 installed.

I installed the clangd indexer and disabled the default indexer per the instructions at this link. The installation of the clangd indexer went smoothly, but to get it to take effect, I had to delete my project and re-import it.

My first problem with the indexer is that it seems to have trouble finding standard C++ headers. It says "Use of undeclared identifier 'std'" when I reference an std library method.

It also claims it can't find the string header file as indicated below. I noticed that this happens with the first #include in the file. So if I first #include then #include it will indicate memory cannot be found but it finds string. Weird.

FInally, I also don't see any context menu commands for "Open declaration". The other indexer supported it. Is that feature unavailable with the clangd indexer?

I've attached the Eclipse log.
eclipse.log

[HighCommander4]

I noticed that this happens with the first #include in the file. So if I first #include then #include it will indicate memory cannot be found but it finds string. Weird.

Note, the lack of diagnostics about subsequent includes is a symptom of the clang parser giving up after failing to resolve the first include; it doesn't even try resolving subsequent ones.

I've attached the Eclipse log. eclipse.log

We'll need clangd logs to diagnose the issue. Maybe @ghentschke can advise how to get those for this editor.

However, the most common solution for this type of issue is to specify --query-driver in clangd's arguments as discussed in the last paragraph of https://clangd.llvm.org/troubleshooting#cant-find-standard-library-headers-map-stdioh-etc.

[ghentschke]

As @HighCommander4 already mentioned is the problem that clangd cannot determine the path to standard library. I think there has been major improvements in cangd version >16 on determining the system includes. The cdt-lsp plugin already uses the
--query-driver command:

Please check if this query driver entry <yourPath>/bin/* fixes this issues, because now the query is limited to a certain compiler (when you've followed the instruction here)

You can enable the Language Server Logging in the Eclispe Preferences here:

[mbratch]

Thank you @ghentschke. I think this highlights the issue.

The tools folder structure for the ESP32 ESP-IDF SDK I'm using is a bit peculiar. This is what I have configured for the Editor (LSP):

Here is the context of the directory structure where the tools are. The include folder that corresponds to the bin folder holding the compiler, shown as item #1, is empty (!). There's another subfolder that has a bin and corresponding include folder (item #2). This bin does not have the compiler, but the corresponding include for that bin is where all the standard include files appear to be. I'm not sure how the Eclipse compiler is picking them up (since the code compiles). I'll need to look around the configuration to see how that's done.

[HighCommander4]

@mbratch Please feel free to share language server logs taken as shown above. Those will indicate what path needs to be specified in the "Drivers" field.

[ghentschke]

This CDT fix might be helpful, since it fixes a bug for cc.exe on Windows.

[mbratch]

Here is my language server log:

lang_server.log

[HighCommander4]

Here is my language server log:

lang_server.log

This contains the LSP traffic, but not the language server's own logs.

As discussed at https://clangd.llvm.org/troubleshooting#gathering-logs (emphasis mine):

Your editor should make clangd’s stderr log available (see installation for how). These describe the messages exchanged between the editor and clangd, and what clangd was thinking.

@ghentschke is there a way to get at clangd's full stderr output with CDT-LSP?

[mbratch]

@HighCommander4 ok sorry for the error. The configuration instructions above indicated checking "log to console", so I naturally assumed I was to capture what was printed on the console. Seems a bit confusing. I'll get the correct log and attach when I get a chance.

[ghentschke]

@HighCommander4 I think this is what you looking for:

I[08:33:54.418] clangd version 16.0.2 (https://github.com/llvm/llvm-project 18ddebe1a1a9bde349441631365f0472e9693520)
I[08:33:54.419] Features: windows+grpc
I[08:33:54.419] PID: 9648
I[08:33:54.419] Working directory: C:\Users\ghent\cdt-main\eclipse
I[08:33:54.419] argv[0]: C:\temp\clangd-windows-16.0.2\clangd_16.0.2\bin\clangd.exe
I[08:33:54.419] argv[1]: --clang-tidy
I[08:33:54.419] argv[2]: --background-index
I[08:33:54.419] argv[3]: --completion-style=detailed
I[08:33:54.419] argv[4]: --pretty
I[08:33:54.419] argv[5]: --query-driver=C:/Daten/msys64/mingw64/bin/*
I[08:33:54.425] Starting LSP over stdin/stdout
I[08:33:54.475] <-- initialize("1")
I[08:33:54.483] --> reply:initialize("1") 8 ms
I[08:33:54.498] <-- initialized
I[08:33:54.508] <-- textDocument/didOpen
I[08:33:54.622] System includes extractor: successfully executed C:\Daten\msys64\mingw64\bin\clang.exe
	got includes: "C:/Daten/msys64/mingw64/include/c++/11.2.0, C:/Daten/msys64/mingw64/include/c++/11.2.0/x86_64-w64-mingw32, C:/Daten/msys64/mingw64/include/c++/11.2.0/backward, C:/Daten/msys64/mingw64/lib/clang/13.0.0/include, C:/Daten/msys64/mingw64/x86_64-w64-mingw32/include, C:/Daten/msys64/mingw64/include"
	got target: "x86_64-w64-windows-gnu"

I've to check how to print this to the Eclipse log.

[HighCommander4]

@HighCommander4 I think this is what you looking for:

Yep, exactly! This contains information printed by clangd (such as the "System includes extractor" line) which is very useful for diagnosing issues of this sort.

Note that there is also more verbose logging (lines starting with V) which can be enabled by adding --log=verbose to the clangd command line, which can also be quite helpful.

[ghentschke]

@mbratch Please run your Eclipse.exe or IDE executable from a command window with the -consolelog argument:
For example:

Eclipse.exe -consolelog

This will open a console window with the logging of the Java process. You should see the clangd log entries as shown in my post above.

[mbratch]

Hello @ghentschke. Thank you for your continued help.

I ran the console log as you suggested, attached here.

eclipse-console-log.txt

[HighCommander4]

I ran the console log as you suggested, attached here.

eclipse-console-log.txt

Based on the log, the issue seems to be the mismatch between the --query-driver argument (which IIUC comes from the "Drivers" field in the "Editors (LSP)" config page), which is C:\Users\mdbra\.espressif\tools\xtensa-esp32-elf\esp-12.2.0_20230208\xtensa-esp32-elf\bin\xtensa-esp32-elf-gcc.exe, and the actual compiler driver from the compile command, which is C:/Users/mdbra/.espressif/tools/xtensa-esp32-elf/esp-12.2.0_20230208/xtensa-esp32-elf/bin/xtensa-esp32-elf-g++.exe.

I think the difference in slashes is fine, since the actual path gets normalized and on Windows the normalized path should have backslashes, and so it's only the gcc vs. g++ that's an issue.

So, I would expect changing the contents of that "Drivers" field to be C:\Users\mdbra\.espressif\tools\xtensa-esp32-elf\esp-12.2.0_20230208\xtensa-esp32-elf\bin\xtensa-esp32-elf-g++.exe should resolve the issue.

[mbratch]

Thank you @HighCommander4, I changed the Drivers field to indicate g++ as you noted, but I am still getting the same problem. Is there anything I need to do after changing the Drivers setting to "re-evaluate"?

[HighCommander4]

Thank you @HighCommander4, I changed the Drivers field to indicate g++ as you noted, but I am still getting the same problem. Is there anything I need to do after changing the Drivers setting to "re-evaluate"?

I think a restart of Eclipse should do it.

If that still doesn't help, could you re-take the logs with --log=verbose added to the "Additional" field (under "Drivers") for a more detailed look?

[HighCommander4]

I think the difference in slashes is fine, since the actual path gets normalized and on Windows the normalized path should have backslashes, and so it's only the gcc vs. g++ that's an issue.

I just realized something: the clangd patch to normalize the driver path has not appeared in a release yet; it will appear in clangd 18.

So, with clangd 17 and earlier, the direction of the slashes is important, and so in your case you'd need to set the "Drivers" field to C:/Users/mdbra/.espressif/tools/xtensa-esp32-elf/esp-12.2.0_20230208/xtensa-esp32-elf/bin/xtensa-esp32-elf-g++.exe.

[mbratch]

Thanks @HighCommander4 that all seems to have cleared up the problem!