On Wed, 2023-05-17 at 17:28 +0300, Eli Zaretskii via Gcc wrote: > If there are no current plans for implementing LSP, I hope someone > will work on that soon, given that Emacs can now use it, and because > having a GCC-based LSP implementation will allow people to use their > installed GCC as the basis for LSP features, instead of having to > install yet another compiler.
Just to note, existing LSP servers are stand-alone binaries: you don't need to install the compiler. The two main C/C++ LSP servers I'm aware of are clangd and ccls. Both of them are built from libclang, as you suggest, but you don't need a full clang installation to get them. You do need to install some Clang "resource" header files for intrinsics etc. but not the entire compiler (for example you don't need the STL or anything like that: they do work fine with the GCC STL). Nevertheless I wholeheartedly agree with your hopes Eli because using Clang-based LSP is annoying for people developing with GCC: First, when you're viewing code that is using #ifdefs to choose between compilers you always see the code for Clang as "active", even though you're using GCC as the compiler, since it's using the Clang built-in macros. More frustratingly, Clang has made some poor decisions around "compatibility": they tried to leverage the GNU ecosystem by emulating GCC features and arguments but sometimes break things. The most egregious example I'm aware of is that they look for GCC-named precompiled headers (.gch), even though the Clang PCH format is completely different. So if Clang (and the LSP servers built on it) find a .gch header file they will try to read it, fail, and give an error. I filed a bug about this in 2019 but it's been ignored. This means you need to modify your LSP server arguments to omit any PCH compiler command line arguments; for environments based on auto- generated definitions like compile_commands.json this is frustrating.
