[libcxx-commits] [PATCH] D92212: Make libcxx work according to Clang C++ Status if -fchar8_t is passed

Yuriy Chernyshov via Phabricator via libcxx-commits libcxx-commits at lists.llvm.org
Tue Dec 1 12:44:19 PST 2020

georgthegreat accepted this revision.
georgthegreat added a comment.

> 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.

> The bottom line is that we don't want to backport arbitrary C++20 features to C++17.

I am sorry if this PR appeared to suggest such thing.

My intention was to show that simply testing `__cplusplus` value is not enough to test if certain feature is supported by compiler or not (I assume that if certain compiler does not fully support specific feature, the library should not implement this feature for this compiler). Though clang11 supports `-std=c++20` , it does not support coroutines, modules, operator spaceship and so on. Should the library (try to) implement these feature based on `__cplusplus` value? I think it should not. So, the options are (values are :

  #if __cpluscplus > 202002L && clang_version_major > 12 && clang_version_minor > 1 //clang versions prior 12.1 do not implement feature support
  //continue testing every known compiler in the world


  #if defined(__cpp_feature) && __cpp_feature > 201702 // assume that compiler follows the standard in preprocessor macro definitions

I would choose the latter without making attempts to switch back to testing `__cplusplus`. There should be a single source of truth.
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).

  rG LLVM Github Monorepo



More information about the libcxx-commits mailing list