Re: LSP based on GCC

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

On Thu, May 18, 2023 at 09:25:04 -0400, Paul Smith wrote:
> On Wed, 2023-05-17 at 18:38 -0400, Ben Boeckel wrote:
> > FWIW, this is only going to get worse with C++ modules.
> 
> There's no reason it should.  Of course the right answer is to tell
> people to fix their build systems and if they want to use a different
> compiler AND use PCH, they use the appropriate suffix for that
> compiler.
> 
> But even if you don't want to do that the fix in this case is trivial.
> I even sent a patch (although since I don't know the clang code there's
> no doubt that it was not done "the right way" and needed to be
> massaged), they just never cared about it.
> 
> The GCC PCH files use a special 4-byte prefix in every file; all you
> have to do in clang is, if you find a .gch file open the file and read
> the first 4 bytes and if it's a real GCC PCH file you ignore it and if
> it's actually a Clang PCH with a malformed name you complain bitterly
> and dump core.... er, I mean, you read it silently as if it had the
> right name.

PCH files can "be ignored" in some sense because they can be
recalculated from `#include` files pretty easily. Module files, however,
cannot.

> One would hope that, if the GCC module files have a similar compiler-
> specific format (I'm not too familiar with modules) they also use a
> similar magic number at the beginning of the file.

GCC module files are use ELF containers, so there's plenty of metadata
to know it's not-for-Clang. But Clang will need to make its own version
of these module files to know what, if anything, is provided by it by
sources that import it to make any kind of useful suggestions.

> But anyway this is losing the thread of Eli's hopeful request.

Agreed. A GCC-based LSP will help immensely with GCC-using projects
(whether it be Emacs or Vim on the other end of the LSP pipe ;) ).

--Ben