Quuxplusone 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)
----------------
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." :)
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
