[libcxx-commits] [PATCH] D92212: Make libcxx work according to Clang C++ Status if -fchar8_t is passed
Louis Dionne via Phabricator via libcxx-commits
libcxx-commits at lists.llvm.org
Tue Dec 1 13:06:53 PST 2020
ldionne added a comment.
In D92212#2426460 <https://reviews.llvm.org/D92212#2426460>, @georgthegreat wrote:
>> You iterate locally, fixing issues and committing them until the whole code base compiles both as C++17 and C++20.
>
> This was the initial plan. The problem arises with u8 literals, as C++20 changes behavior of u8"" literals in an incompatible way. Hence there is no way to use these literals in a codebase which is compatible with both C++17 and C++20. My idea was to remove the literals once, then enable `-fchar8_t` feature flag to prevent new improperly used literals from appearance.
>
> I have implemented the test to check if everything works and it turned out that is just does not.
Did you try something like what https://stackoverflow.com/a/56833374/627587 suggests?
> I would choose the latter without making attempts to switch back to testing `__cplusplus`. There should be a single source of truth.
The issue with keeping these conditionals based on `__cpp_feature` instead of the actual standard version is that in the long term, you end up with a lot of these conditionals. There's then an expectation that the code base works with arbitrary combinations of those being defined, which isn't realistic. Instead, if the majority of conditionals use the standard version, you know for sure that those code paths are being tested, and they're working as intended. It also reduces the cognitive burden since you can take for granted that `-std=c++20` means "everything in C++20 will work", with very few exceptions.
> I am fine with the changes (and, as I said, non-applying them would not block the migration process; I will apply the diff which solves my issue to a local copy of libcxx).
I think it's fairly important for us to decide which way we're taking the project, since similar questions will happen in the future. We're not only having a discussion about `char8_t` here, we're having a design discussion about how to handle feature test macros defined by the compiler.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D92212/new/
https://reviews.llvm.org/D92212
More information about the libcxx-commits
mailing list