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