rsmith added inline comments.
================
Comment at: clang/lib/Frontend/InitPreprocessor.cpp:593-594
+ // C++2b features.
+ if (LangOpts.CPlusPlus2b)
+ Builder.defineMacro("__cpp_size_t_suffix", "202011L");
if (LangOpts.Char8)
----------------
Quuxplusone wrote:
> AntonBikineev wrote:
> > AntonBikineev wrote:
> > > Quuxplusone wrote:
> > > > aaron.ballman wrote:
> > > > > AntonBikineev wrote:
> > > > > > aaron.ballman wrote:
> > > > > > > Because we allow this as an extension in all C++ modes, should
> > > > > > > this be enabled always rather than gated on C++2b?
> > > > > > I was also wondering about this. I've checked that we also do the
> > > > > > same for other feature macros, such as __cpp_binary_literals, which
> > > > > > is defined for -std>=c++14 while at the same time is allowed as an
> > > > > > extension before C++14. Therefore I decided to mimic the behaviour.
> > > > > Thanks for checking on that! I think that seems defensible enough. :-)
> > > > Btw, thus far libc++ has tended to make the opposite choice: for
> > > > example, libc++ defines `__cpp_lib_variant == 202102` in all modes,
> > > > because the programmer conceivably might be depending on that macro to
> > > > make some decision, so we want to make sure it reflects the specific
> > > > semantics that we implement. (For `__cpp_binary_literals`
> > > > specifically, I agree it doesn't really matter because nobody's going
> > > > to be making decisions based on the value of this macro.)
> > > >
> > > > See https://reviews.llvm.org/D99290#inline-934563 (D96385, D97394) for
> > > > previous discussions on the libc++ side.
> > > Thanks for pointing this out, Arthur.
> > >
> > > I wish there was some consistency, however, I'm not sure if this is
> > > easily feasible. I guess the strategy of defining `__cpp_size_t_literals`
> > > on all modes would be problematic, since if the user code depends on
> > > `__cpp_size_t_literals`, it could suddenly receive the extension warning
> > > (when compiled with -std<2++2b), which is enabled by default.
> > > Btw, thus far libc++ has tended to make the opposite choice: for example,
> > > libc++ defines `__cpp_lib_variant == 202102` in all modes, because the
> > > programmer conceivably might be depending on that macro to make some
> > > decision, so we want to make sure it reflects the specific semantics that
> > > we implement. (For `__cpp_binary_literals` specifically, I agree it
> > > doesn't really matter because nobody's going to be making decisions based
> > > on the value of this macro.)
> > >
> > > See https://reviews.llvm.org/D99290#inline-934563 (D96385, D97394) for
> > > previous discussions on the libc++ side.
> >
> >
> > I guess the strategy of defining `__cpp_size_t_literals` in all modes would
> > be problematic, since if the [pre-C++2b] user code depends on
> > `__cpp_size_t_literals`, it could suddenly receive the extension warning...
>
> Ah, yes. Orthogonally to everything I said above, I think it's fair to say
> that
> - in modes where `42uz` produces a fatal error, it's definitely "not
> supported"
> - in modes where it's accepted without complaint, it's definitely "supported"
> (*)
> - in modes where it produces a non-fatal warning, you can plausibly argue it
> either way
> (*) - with a bonus exception that if the user passes `-Wno-blah` or `-w`,
> that doesn't magically make things be supported
> libc++'s situation seems more black-and-white; e.g. `variant` behaves one way
> or the other. There's no libc++ equivalent of "you get the new behavior but
> with a warning." :)
We have some prior art to draw on here: our `__has_extension(X)` behavior is
that under `-pedantic-errors`, we don't advertise any extensions beyond the
`__has_feature(X)` set, and otherwise we advertise features even if they will
lead to warnings (or errors via `-Werror` or `-Werror=pedantic` or similar
warning flags).
I'm not sure that's necessarily the best thing, since it's only loosely
connected to whether the construct in question would lead to (warnings or)
errors, but it's consistent with the principle that warning flags shouldn't
change behavior (beyond which warnings or errors are emitted) and probably more
useful than never advertising extensions in earlier language modes.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D99456/new/
https://reviews.llvm.org/D99456
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
