dev_17.0.6

Vvarconst[libc++][ranges] Implement the changes to basic_string from P1206 (ranges::to):

baf6f918创建于 2023年7月6日历史提交

文件	最后提交记录	最后更新时间
basic.string.hash	[libc++] Move all the remaining .fail.cpp tests to .verify.cpp I made sure they all had some expected-error output in them. Many of these tests would be better implemented as a positive test using SFINAE, but this is beyond the scope of this patch. Differential Revision: https://reviews.llvm.org/D153980	3 年前
basic.string.literals	[libc++] Granularize <type_traits> includes Reviewed By: ldionne, #libc, #libc_abi Spies: #libc_vendors, smeenai, libcxx-commits Differential Revision: https://reviews.llvm.org/D145320	3 年前
basic.string	[libc++][ranges] Implement the changes to basic_string from P1206 (ranges::to): - add the from_range_t constructors and the related deduction guides; - add the insert_range/assign_range/etc. member functions. (Note: this patch is split from https://reviews.llvm.org/D142335) Differential Revision: https://reviews.llvm.org/D149832	3 年前
c.strings	[libc++] Consistently enable __CORRECT_ISO_CPP_WCHAR_H_PROTO in mbstate. In libc++'s wchar.h, before we forward to the system wchar.h, we set __CORRECT_ISO_CPP_WCHAR_H_PROTO to ensure it defines the correct signature (e.g. extern "C++" const wchar_t *wmemchr and not extern wchar_t *wmemchr). After D148542, there are cases where we include the system wchar.h from within __mbstate_t.h without setting that, and so we get a function type mismatch if we transitively include wchar.h through multiple headers in a modules-enabled build. Consistently setting it here resolves those build errors. Alternative 1: we could put this in __config instead. I chose to put it here for a more limited scope. Alternative 2: we could patch wchar.h itself to work correctly and remove references __CORRECT_ISO_CPP_WCHAR_H_PROTO from libc++ entirely. It does already set it, but with an additional condition that it is being built by GCC >= 4.4. Clang does pretend to be GCC via __GNUC__ etc. which can be controlled via -fgnuc-version command line flags, but that might have other consequences. Reviewed By: ldionne, #libc, MaskRay Differential Revision: https://reviews.llvm.org/D150015	3 年前
char.traits	[libc++] Use the __is_trivially_equality_comparable builtin Reviewed By: ldionne, #libc Spies: libcxx-commits Differential Revision: https://reviews.llvm.org/D148553	3 年前
string.classes	[libc++][test] Use TEST_HAS_NO_CHAR8_T to simplify #ifdefs. NFCI. Many tests in libcxx/test/std/strings use #if defined(__cpp_lib_char8_t) && __cpp_lib_char8_t >= 201811L which can be replaced with the more terse #ifndef TEST_HAS_NO_CHAR8_T. Differential Revision: https://reviews.llvm.org/D132626	4 年前
string.conversions	[libc++] Qualifies size_t. This has been done using the following command find libcxx/test -type f -exec perl -pi -e 's|^([^/]+?)((?<!::)size_t)|\1std::\2|' \{} \; And manually removed some false positives in std/depr/depr.c.headers. The std module doesn't export ::size_t, this is a preparation for that module. Reviewed By: ldionne, #libc, EricWF, philnik Differential Revision: https://reviews.llvm.org/D146088	3 年前
string.view	[libc++] Move all the remaining .fail.cpp tests to .verify.cpp I made sure they all had some expected-error output in them. Many of these tests would be better implemented as a positive test using SFINAE, but this is beyond the scope of this patch. Differential Revision: https://reviews.llvm.org/D153980	3 年前
strings.erasure	[libc++] Qualifies size_t. This has been done using the following command find libcxx/test -type f -exec perl -pi -e 's|^([^/]+?)((?<!::)size_t)|\1std::\2|' \{} \; And manually removed some false positives in std/depr/depr.c.headers. The std module doesn't export ::size_t, this is a preparation for that module. Reviewed By: ldionne, #libc, EricWF, philnik Differential Revision: https://reviews.llvm.org/D146088	3 年前
strings.general	[libc++] Remove "// -*- C++ -*-" comments from all .cpp files. NFCI. Even if these comments have a benefit in .h files (for editors that care about language but can't be configured to treat .h as C++ code), they certainly have no benefit for files with the .cpp extension. Discussed in D110794.	4 年前