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?
>
> 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?).
Is that something we actually support though? I think we don't (meaningfully)
support separate compilation like that because we run the preprocessor
*always*, including on code that came originally from `-E` output. So I think
there's actually more work to be done and Ambrose is just starting to scratch
the surface. There's a reason GCC added `-fpreprocessed` for consuming
already-preprocessed sources.
> 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.
I won't block a more generalized spelling, but I would probably put my foot
down for generalizing it enough that it looks like a user-facing feature. e.g.,
naming it `#pragma clang define_macro()` would be problematic but `#pragma
clang __library_support_hack_macro_definition()` or something is sufficiently
scary (it doesn't have to be that obnoxiously named though).
https://github.com/llvm/llvm-project/pull/210802
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
