- User Since
- May 4 2020, 6:10 AM (48 w, 6 d)
Mar 3 2021
Ok, I am discarding this PR for the time being.
Mar 2 2021
Ok, I have run CI check on a large codebase too.
Mar 1 2021
I have implemented similar patch in all headers mentioned in C++ working draft as reserved / removed.
NB: At the time <ciso646> already causes trouble. People are expecting it to behave just like <iso646.h>. This works for most of the headers — you can replace <string.h> with <cstring> and get string.h transitively included, but does not work with this one.
Feb 28 2021
@ldionne, I have changed the behavior to cause an error if the user includes <ciso646> expecting certain behavior from the standard library.
Feb 16 2021
MSVC only recognizes the alternative tokens in strict (/permissive-) mode to avoid breaking legacy code that uses those lexemes as identifiers. I have no opinion on whether or not libc++ should accept this change, but I strongly recommend that C++ code that wants portable conformant behavior when compiling with MSVC should use /permissive-, which will finally be on-by-default in C++20 mode.
@ldionne, actually, I was talking about standard-bound #error, as follows:
I have digged through C++ Working Draft and found the following:
Dec 5 2020
The final revision is buildable and can be merged.
@ldionne, could you merge it?
The attempt to test std::hash via _gnu_cxx was just wrong.
I can not find any place to put individual hash tests anywhere, so I am removing the test completely.
Dec 3 2020
Ok, I got you point.
I would not use this approach for migration though.
Should not we remove || !defined(__cpp_char8_t) part of LIBCPP_NO_HAS_CHAR8_T then?
This looks like an attempt to support compilation with -std=c++20 -fnochar8_t which is the most weird mode ever (and it is not tested via CI)
btw, I am ok to limit this behavior to -std=c++17. Condition in <version> might be changed as follows:
Dec 2 2020
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.
Did you try something like what https://stackoverflow.com/a/56833374/627587 suggests?
Dec 1 2020
You iterate locally, fixing issues and committing them until the whole code base compiles both as C++17 and C++20.
Just fix the logical expression without introducing radical changes to libc++ logic
Use libc++-specific macro to rest if hashing should be enabled.
Nov 30 2020
As for the 2, I can not understand why libcxx should have any logic depending on the compiler feature support. Could you elaborate / invent artificial scenario when such logic is necessary?
- My thoughts are quite different. This macro requires double negation upon usage: #ifndef _LIBCPP_NO_HAS_CHAR8_T. I personally find troubles reading any negation. #ifdef __cpp_char8_t is much shorter and easier to understand. And it is standartized!
There is a chance that _LIBCPP_NO_HAS_CHAR8_T should be removed in the course of https://reviews.llvm.org/D92212
Nov 29 2020
Nov 28 2020
Found the official explanation and motivation regarding the feature testing macros.
See, e. g.:
@ldionne, this PR appeared as a part of a large monorepo migration to a new standard.
If I just change -std=c++17 to -std=c++20, thousands of new errors appear (even upon switching off all the major deprecation warnings), so I am trying to split the switch into smaller parts and fix them one by one.
New standard changes behavior of u8"" literals in an incompatible way, so I have to remove these literals from the codebase and prevent new std::string = u8"blah" lines from appearance.
Nov 27 2020
Another thing to consider is that -fchar8_t changes the behavior of u8"" literals, hence they can no longer be assigned to old good std::string-types.
At the time libcxx provides no alternative.
Nov 5 2020
@dblaikie, so, could you, please, commit this at last?
Changed as dblaikie@ suggested. Not all the types are handled during the switch, so default is still required in order to prevent compiler from issuing warnings.
Nov 3 2020
So, could someone, please, commit this PR? I have no write access to llvm.
Restore unreachable return statement, upon mclow.lists@ request.
Sep 26 2020
Sep 15 2020
Sep 6 2020
I have no commit access to llvm monorepo, so could, please, someone land this commit?
Sep 5 2020
May 18 2020
I have just submitted P2166R0 to LEWG-I, LEWG, LWG.
While the proposal is not published, this link can be used to preview it.
May 6 2020
If you know that the size of your data is always zero, you should use default ctor, shouldn't you?
Indeed, the proposed change does not allow to get rid of runtime checks — it just makes invalid cases easier to detect.
As for the rarity, I have applied these changes (both to std::string_view and std::string) and ran CI checks over a private monorepo.
It gave me 7 possible problematic places, one of which would actually lead to a segfault, if reached in runtime (the code was actually reachable). Most of the problems are caused by contrib code, including projects like