[clang] [Clang] Support libstdc++ workarounds when using `-E` (PR #210802)

[Erich Keane via cfe-commits]

erichkeane wrote:

> > > > I like this approach a lot, in that in think the approach is workable. However I'm concerned that it's too ad-hoc. We know we will want to preserve _MSC_VER too, for example (but also __INTRIN_H, maybe other)
> > > > can we do `#pragma clang define name value` ?
> > > 
> > > 
> > > @Sirraide and I talked about that approach and I would _really_ prefer to avoid it because it opens up all kinds of messy problems that require careful thought. e.g., do we also then need an undefine because users can define and undefine the macros? what happens if the user does `#define FOO _Pragma("clang define name value")`? That kind of thing.
> > > We convinced ourselves that it makes more sense to do a non-general solution here because we want this to stay in the realm of "implementation detail hack" and not "something users should use themselves".
> > > WDYT?
> > 
> > 
> > I personally definitely fear we're going to end up with something else like this again and just have a ton of extra code. However, I see the value here as effectively/exclusively a "version number capture/hackery". I wonder if we could do `#pragma clang define_lib_val NAME PP_INT`?
> > the name there obviously needs work, but the idea is: Only allow names (perhaps even 'reserved' named?) plus an integer literal?
> > IF we decide to do more than 2-3 of these, I'd desperately want us to have some sort of 'list generated' version of these on the name when we see a `#define`. From the sound of it from corentin, we've already got 2 in mind... maybe its worth generalizing this slightly?
> 
> AFAICT, the only issue we have is with `__GLIBCXX_`. We have `Preprocessor::getStdLibCxxVersion()` but I don't see us looking for other standard library macros currently. So I think we have some possibilities in mind but no actual needs currently. We could do some amount of generalization to make the second one easier, but we could just do that generalization when we have a need? Hmm I suppose there's a case where the user uses Clang 24.x with -E to emit source code that's then compiled by Clang 25.x so we might have to keep the old hack around. But I also don't know if that's really a supported use case (particularly given our lack of support for `-fpreprocessed`), so maybe we can just replace the hack with a generalized one in the future?

Its a bit of a Hyrem's law for me?  I'd like to avoid having this be a special-case of special-case that we have to keep around forever because someone discovered this/shipped it on their platform (which could very reasonably happen as offload vendors might preprocess it to have as a "stable" version of the Standard Library" for device side?).

So a more general SPELLING would be appreciated (even if we just have a "How DARE You spell anything but `__GLIBCXX__`!" error) for that reason.

https://github.com/llvm/llvm-project/pull/210802