On Wed, 2023-05-17 at 18:38 -0400, Ben Boeckel wrote: > > 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.
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. 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. But anyway this is losing the thread of Eli's hopeful request.
