> You really shouldn't be using Clang in production because it has all sorts of hard limitations

Wait, do you mean you shouldn't be using Clang PCHs in production, or shouldn't be using Clang in production at all?

At all. Clang has a lot of footguns, and filing bugs about "regression compared to GCC" does not actually get them fixed.

Remember, the whole point of Clang is so that people can make their proprietary compiler forks. Everything else, including quality, is secondary.

	▲	nuudlman 2 days ago \| parent [-]
		Do you have any specific examples here? While no compiler is perfect (e.g., pointer provenance), one could just as easily argue that Clang has higher quality—most modern C/++ tooling is built on it, sanitizers are brought up in Clang and sometimes ported to GCC later, all of the modern safety work is in Clang (-Wbounds-safety, the various thread safety approaches, lifetime analysis, Sean’s borrow checked C++, Fil-C). The Clang static analyzer has also been used in production for over a decade, whereas -fanalyzer is still experimental and limited to C, … I have the feeling that the bugs that aren’t being fixed are either because the bug report is unactionable (3yr old Ubuntu Franken-clang is slower than than 3yr old franken-gcc) or because the problem is very non-trivial (e.g., you can find recent discussion about enabling dependence analysis by default, the aforementioned pointer provenance issues stemming from C, ABI/lowering warts around large _BitInt)