Re: LSP based on GCC

[Paul Smith <paul@mad-scientist.net>]

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.