the next lsp4E release will break esp ide i filed an intial bug in eclipse cdt but they specified you're using a non api which is going to be removed in the next version$. https://github.com/eclipse-cdt/cdt-lsp/issues/402

[emaayan]

No description provided.

[jonahgraham]

BTW, not LSPE4E release, but CDT LSP release. eclipse-cdt/cdt-lsp#402

Espressif, you are more than welcome to use non-API code in CDT LSP, but unfortunately that seems to be having knock on effect for your users like @emaayan.

Please submit a PR to CDT LSP if you want things which are not currently API to be made API. For example you have suppressed warnings in places such as

idf-eclipse-plugin/bundles/com.espressif.idf.core/src/com/espressif/idf/core/util/LspService.java

Line 19 in c5d6a64

@SuppressWarnings("restriction")

In the meantime can you communicate to your users that they can't upgrade Espressif to newer CDT LSP versions.

PS Any contributions from Espressif to CDT LSP (and the wider Eclipse ecosystem) would be appreciated. For example CDT 12 is refactoring a bunch of stuff related to Core Build for CMake files.

[emaayan]

BTW, not LSPE4E release, but CDT LSP release. eclipse-cdt/cdt-lsp#402

Espressif, you are more than welcome to use non-API code in CDT LSP, but unfortunately that seems to be having knock on effect for your users like @emaayan.

Please submit a PR to CDT LSP if you want things which are not currently API to be made API. For example you have suppressed warnings in places such as

idf-eclipse-plugin/bundles/com.espressif.idf.core/src/com/espressif/idf/core/util/LspService.java

Line 19 in c5d6a64

@SuppressWarnings("restriction")

In the meantime can you communicate to your users that they can't upgrade Espressif to newer CDT LSP versions.

PS Any contributions from Espressif to CDT LSP (and the wider Eclipse ecosystem) would be appreciated. For example CDT 12 is refactoring a bunch of stuff related to Core Build for CMake files.

sorry, wasn't sure exactly sure which is which, TBH i'm still not sure how entire LSP mechanism works in general, i mean from my POV, during build espessif uses shell which uses python which runs esp idf tools which opens another shell to run cmake which generates scripts to be run by ninja which is the actual build system the runs the actual compiler . (and sometimes cmake would also run another python tool on it's own for partition and file managment).
how does clangd fit into all of this? the reason i'm asking is there could discprenecies between the ide compiler and the actual build , most notably during macros, for example doing

long i;
ESP_LOGI(tag,"out var" PRIu32, long i)

and you use the wrong macro for the type, the cmake build does insane, spitting massive amount of errors, but you won't see anything in regular problems view, which suggest it's not the same compiler.

[kolipakakondal]

Hi @jonahgraham Thanks for bringing this up. I am pushing the team to contribute directly to the CDT/CDT LSP repos if we see something worth refactoring or contributing, and align with the eclispe timelines.