Re: LSP based on GCC

[Ben Boeckel <ben.boeckel@kitware.com>]

On Wed, May 17, 2023 at 15:48:09 -0400, Paul Smith wrote:
> 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

Alas, the cost of trying to make a compiler that can injest in-the-wild
code. It's the reason "every" compiler claims various GCC things: too
many projects ended up with `#error "Unknown compiler"` in their
detections and fixing them when you're just trying to get off the ground
is annoying. As far as I know, GCC is locked into never providing a
single uniquely identifiable trait because other compilers would end up
having to emulate it too once it gets used by projects. CMake basically
just ends up with "it's GCC" if `__GNUC__` is defined and none of the
other, more specific, preprocessor markers are present.

We're kind of getting this again with the variety of different frontends
available on top of Clang these days (Apple's Xcode build, upstream
itself, Intel's frontend, IBM's LLVM-based frontend, the XL-alike Clang
build, Fujitsu has one, ARM's, and who knows how many others are out
there). Sometimes they've…forgotten to make something distinctive so
that it can be detected reliably.

> 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.

FWIW, this is only going to get worse with C++ modules.

--Ben