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?).
>
> 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).
I mean... we already DO? A `-fpreprocessed` could potentially help us hack
around some of these fixes/shorten compile time slightly, but we'd still need
to consume the text. Presumably all that would do is instruct us that we can't
count on PP hackery (like the 'before' version of this) or macro expansion, but
even that seems like a 'drop in the bucket' value wise.
At least SYCL shipped some preprocessed code for a while (as well as all of the
offload models have some level of 'preprocess'). A few of the offload models
have a "preprocess code with one compiler, then feed it to host and device
compiler". Forcing their preprocessor to be aware of WHICH version of the
hack-pragma we're using seems unnecessarily combative.
I also don't care about the spelling as much as the fact that it is something
that stays general and will be unchanged long-term. Name it `#pragma clang
__I_better_not_catch_you_using_this_so_help_me_I_will_turn_this_compiler_around_and_we_can_just_eat_broccolli'
for all I care.
https://github.com/llvm/llvm-project/pull/210802
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
