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
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
