[PATCH] D136449: [Clang] Implement P2513
Aaron Ballman via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Fri Oct 21 12:23:46 PDT 2022
aaron.ballman added inline comments.
================
Comment at: clang/lib/Frontend/InitPreprocessor.cpp:701
+ Builder.defineMacro("__cpp_char8_t",
+ LangOpts.CPlusPlus20 ? "202207L" : "201811L");
Builder.defineMacro("__cpp_impl_destroying_delete", "201806L");
----------------
cor3ntin wrote:
> aaron.ballman wrote:
> > Why do we not want to go with `202207L` regardless of language mode if this is being applied as a DR?
> There is a `-fchar8_t` that is an extension before C++20 and we are not touching that. It is pre-existing that the feature test macro was defined before c++20 if that flag was set.
Ahhhh, I see now that there's a (small) potential for breakage (thank you for that test case btw) and so you want to leave the extension flag behavior alone. We usually don't do that (usually these sort of extension flags enable the feature as it exists in the language mode enabling support for it) unless there's a good reason to do so. My thinking is:
The potential for breakage is small enough we're not even going to call it out as a potentially disruptive change in the release notes. Presuming there are likely more people using `-std=c++20` than there are using `-fchar8_t`, changing `-fchar8_t` seems like less risky behavior than changing `-std=c++20`. So I think it's reasonable for us to enable this functionality for `-fchar8_t` as well because we're already assuming the larger risk.
WDYT?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D136449/new/
https://reviews.llvm.org/D136449
More information about the cfe-commits
mailing list