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
