TTobias HietaBump version to 17.0.6
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[libc++][Modules] Fix a few module related warnings I'm getting a few -Wundefined-inline warnings, and a -Wnon-modular-include-in-module too. Fix all of those. Reviewed By: Mordante, #libc Differential Revision: https://reviews.llvm.org/D156508 (cherry picked from commit 165841b681c146ae1e013a0aa4d69ef7c7c20fe2) | 2 年前 | |
[libc++][NFC] Use _LIBCPP_STD_VER instead of __cpp_lib_atomic_is_always_lock_free Reviewed By: #libc, ldionne, Mordante Spies: Mordante, libcxx-commits Differential Revision: https://reviews.llvm.org/D150421 | 3 年前 | |
[libc++][hardening][NFC] Introduce _LIBCPP_ASSERT_UNCATEGORIZED. Replace most uses of _LIBCPP_ASSERT with _LIBCPP_ASSERT_UNCATEGORIZED. This is done as a prerequisite to introducing hardened mode to libc++. The idea is to make enabling assertions an opt-in with (somewhat) fine-grained controls over which categories of assertions are enabled. The vast majority of assertions are currently uncategorized; the new macro will allow turning on _LIBCPP_ASSERT (the underlying mechanism for all kinds of assertions) without enabling all the uncategorized assertions (in the future; this patch preserves the current behavior). Differential Revision: https://reviews.llvm.org/D153816 | 2 年前 | |
[libc++][hardening][NFC] Introduce _LIBCPP_ASSERT_UNCATEGORIZED. Replace most uses of _LIBCPP_ASSERT with _LIBCPP_ASSERT_UNCATEGORIZED. This is done as a prerequisite to introducing hardened mode to libc++. The idea is to make enabling assertions an opt-in with (somewhat) fine-grained controls over which categories of assertions are enabled. The vast majority of assertions are currently uncategorized; the new macro will allow turning on _LIBCPP_ASSERT (the underlying mechanism for all kinds of assertions) without enabling all the uncategorized assertions (in the future; this patch preserves the current behavior). Differential Revision: https://reviews.llvm.org/D153816 | 2 年前 | |
[libc++] Fix template parameter naming and enforce it through readability-identifier-naming Reviewed By: #libc, Mordante Spies: Mordante, aheejin, libcxx-commits Differential Revision: https://reviews.llvm.org/D156059 | 2 年前 | |
[libc++] Module fixes for __synth_three_way. These changes make it possible to use __synth_three_way in modules. The change from a lambda to a function is a Clang issue. The change is list was needed since the compiler couldn't deduce the comparison template argument. Adds a few missing includes too. Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D146545 | 3 年前 | |
Fixing conflicting macro definitions between curses.h and the standard library. POSIX allows certain macros to exist with generic names (i.e. refresh(), move(), and erase()) to exist in curses.h which conflict with functions found in std::filesystem, among others. This patch undefs the macros in question and adds them to LIBCPP_PUSH_MACROS and LIBCPP_POP_MACROS. Reviewed By: #libc, philnik, ldionne Differential Revision: https://reviews.llvm.org/D147356 | 2 年前 | |
[libc++] Move __thread_id out of <__threading_support> This makes <__threading_support> closer to handling only the bridge between the system's implementation of threading and the rest of libc++. Differential Revision: https://reviews.llvm.org/D154464 | 2 年前 | |
[libc++][hardening][NFC] Introduce _LIBCPP_ASSERT_UNCATEGORIZED. Replace most uses of _LIBCPP_ASSERT with _LIBCPP_ASSERT_UNCATEGORIZED. This is done as a prerequisite to introducing hardened mode to libc++. The idea is to make enabling assertions an opt-in with (somewhat) fine-grained controls over which categories of assertions are enabled. The vast majority of assertions are currently uncategorized; the new macro will allow turning on _LIBCPP_ASSERT (the underlying mechanism for all kinds of assertions) without enabling all the uncategorized assertions (in the future; this patch preserves the current behavior). Differential Revision: https://reviews.llvm.org/D153816 | 2 年前 | |
[libc++][hardening][NFC] Introduce _LIBCPP_ASSERT_UNCATEGORIZED. Replace most uses of _LIBCPP_ASSERT with _LIBCPP_ASSERT_UNCATEGORIZED. This is done as a prerequisite to introducing hardened mode to libc++. The idea is to make enabling assertions an opt-in with (somewhat) fine-grained controls over which categories of assertions are enabled. The vast majority of assertions are currently uncategorized; the new macro will allow turning on _LIBCPP_ASSERT (the underlying mechanism for all kinds of assertions) without enabling all the uncategorized assertions (in the future; this patch preserves the current behavior). Differential Revision: https://reviews.llvm.org/D153816 | 2 年前 | |
[libc++] Merge _LIBCPP_FUNC_VIS, _LIBCPP_TYPE_VIS and _LIBCPP_EXCEPTION_ABI into _LIBCPP_EXPORTED_FROM_ABI These macros are always defined identically, so we can simplify the code a bit by merging them. Reviewed By: ldionne, #libc Spies: libcxx-commits, krytarowski, smeenai Differential Revision: https://reviews.llvm.org/D152652 | 3 年前 | |
[libc++] Fix UB in <expected> related to "has value" flag (#68552) (#68733) The calls to std::construct_at might overwrite the previously set __has_value_ flag in the case where the flag is overlapping with the actual value or error being stored (since we use [[no_unique_address]]). To fix this issue, this patch ensures that we initialize the __has_value_ flag after we call std::construct_at. Fixes #68552 (cherry picked from commit 134c91595568ea1335b22e559f20c1a488ea270e) | 2 年前 | |
[libc++][Modules] Make module exports consistent with header includes Some modules export modules that they don't import (i.e. that their header doesn't directly include). That sometimes works when the exported submodule is in the same module, but when the std mega module is broken up (D144322), some of the exports stop working. Make the exports and includes consistent, either by adding includes for the exports, or by removing exports for missing includes. The concepts.equality_comparable export in std.iterator.__iterator.concepts isn't doing anything because 1) it's resolved as std.iterator.__iterator.concepts.equality_comparable and 2) there's a __concepts submodule in between std.concepts and equality_comparable. Fix it to be std.concepts.__concepts.equality_comparable. <span> is listed in both std.span and std.experimental.span. Delete the latter module. There is no __errc module or header, so remove that export from std.system_error. Reviewed By: ldionne, #libc Differential Revision: https://reviews.llvm.org/D153211 | 2 年前 | |
[libc++][format] Fixes out of bounds access. Fixes https://llvm.org/PR65011 Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D158940 (cherry picked from commit 8930d04d5580c6a2cf04545c87387cd150cd7b46) | 2 年前 | |
[libc++] Fix template parameter naming and enforce it through readability-identifier-naming Reviewed By: #libc, Mordante Spies: Mordante, aheejin, libcxx-commits Differential Revision: https://reviews.llvm.org/D156059 | 2 年前 | |
[libc++] Fix template parameter naming and enforce it through readability-identifier-naming Reviewed By: #libc, Mordante Spies: Mordante, aheejin, libcxx-commits Differential Revision: https://reviews.llvm.org/D156059 | 2 年前 | |
[libc++] Revert "Protect users from relying on detail headers" & related changes This commit reverts 5aaefa51 (and also partly 7f285f48e77 and b6d75682f9, which were related to the original commit). As landed, 5aaefa51 had unintended consequences on some downstream bots and didn't have proper coverage upstream due to a few subtle things. Implementing this is something we should do in libc++, however we'll first need to address a few issues listed in https://reviews.llvm.org/D106124#3349710. Differential Revision: https://reviews.llvm.org/D120683 | 4 年前 | |
[libc++][hardening] Categorize most assertions inside the container classes. This introduces: - _LIBCPP_ASSERT_VALID_INPUT_RANGE; - _LIBCPP_ASSERT_VALID_CONTAINER_ACCESS; - _LIBCPP_ASSERT_VALID_ITERATOR_ACCESS; - _LIBCPP_ASSERT_VALID_ALLOCATOR; - _LIBCPP_ASSERT_INTERNAL. Differential Revision: https://reviews.llvm.org/D155349 | 2 年前 | |
[libc++][Modules] locale fails to compile with clang modules when _LIBCPP_LOCALE__L_EXTENSIONS is undefined When __locale_dir/locale_base_api/locale_guard.h is compiled independently, as it is when it's in its own clang module, it fails to compile due to locale_t being undefined. It needs to include __locale to get that, instead of just clocale. Reviewed By: ldionne, #libc Differential Revision: https://reviews.llvm.org/D158669 (cherry picked from commit 6021c78fe55e3c4d3e073710bfe279c6a28566d4) | 2 年前 | |
[libc++][mdspan] Fix layout_left::stride(r) It was using the stride calculation of layout_right. Reviewed By: philnik Differential Revision: https://reviews.llvm.org/D157065 (cherry picked from commit 0f4d7d81c9d08512a3871596fa2a14b737233c80) | 2 年前 | |
[libc++] Use correct size for deallocation of arrays in shared_ptr (#68233) Fixes #68051. Current implementation passes the number of _AlignedStorage objects when it calls to allocate and the number of **bytes** on deallocate. This only applies to allocations that allocate control block and the storage together, i.e. make_shared and allocate_shared. Found by ASan under Clang combined with -fsized-deallocation. (cherry picked from commit f722db02d359e29ca001b78197ee1a275f8c3d7c) | 2 年前 | |
[libc++][Modules] Add missing __fwd includes A few __fwd includes are missing from public modules that will become noticeable when the private submodules are split into their own top level modules (D144322). Add the missing includes. Reviewed By: ldionne, philnik, #libc Differential Revision: https://reviews.llvm.org/D153216 | 2 年前 | |
[libc++] Merge _LIBCPP_FUNC_VIS, _LIBCPP_TYPE_VIS and _LIBCPP_EXCEPTION_ABI into _LIBCPP_EXPORTED_FROM_ABI These macros are always defined identically, so we can simplify the code a bit by merging them. Reviewed By: ldionne, #libc Spies: libcxx-commits, krytarowski, smeenai Differential Revision: https://reviews.llvm.org/D152652 | 3 年前 | |
[libc++][PSTL] Add a GCD backend Reviewed By: ldionne, #libc Spies: arichardson, mgrang, krytarowski, libcxx-commits, h-vetinari Differential Revision: https://reviews.llvm.org/D151717 | 2 年前 | |
[libc++][hardening][NFC] Introduce _LIBCPP_ASSERT_UNCATEGORIZED. Replace most uses of _LIBCPP_ASSERT with _LIBCPP_ASSERT_UNCATEGORIZED. This is done as a prerequisite to introducing hardened mode to libc++. The idea is to make enabling assertions an opt-in with (somewhat) fine-grained controls over which categories of assertions are enabled. The vast majority of assertions are currently uncategorized; the new macro will allow turning on _LIBCPP_ASSERT (the underlying mechanism for all kinds of assertions) without enabling all the uncategorized assertions (in the future; this patch preserves the current behavior). Differential Revision: https://reviews.llvm.org/D153816 | 2 年前 | |
[libc++][hardening][NFC] Introduce _LIBCPP_ASSERT_UNCATEGORIZED. Replace most uses of _LIBCPP_ASSERT with _LIBCPP_ASSERT_UNCATEGORIZED. This is done as a prerequisite to introducing hardened mode to libc++. The idea is to make enabling assertions an opt-in with (somewhat) fine-grained controls over which categories of assertions are enabled. The vast majority of assertions are currently uncategorized; the new macro will allow turning on _LIBCPP_ASSERT (the underlying mechanism for all kinds of assertions) without enabling all the uncategorized assertions (in the future; this patch preserves the current behavior). Differential Revision: https://reviews.llvm.org/D153816 | 2 年前 | |
[libc++][ranges] Implement ranges::to. Differential Revision: https://reviews.llvm.org/D142335 | 2 年前 | |
[libc++] Fix template parameter naming and enforce it through readability-identifier-naming Reviewed By: #libc, Mordante Spies: Mordante, aheejin, libcxx-commits Differential Revision: https://reviews.llvm.org/D156059 | 2 年前 | |
[libc++][hardening] Categorize more assertions. Differential Revision: https://reviews.llvm.org/D155873 | 2 年前 | |
libcxx: Bring back unsigned return from wcstoull_l Got removed here: 21d9282ae2b6e1e7dfbabfd87f6208c3bdff8ea4#diff-e41832b8aa26da45585a57c5111531f2e1d07e91a67c4f8bf1cd6d566ae45a2bR40 Reviewed By: #libc, philnik Differential Revision: https://reviews.llvm.org/D148056 | 2 年前 | |
[libc++][Modules] Make module exports consistent with header includes Some modules export modules that they don't import (i.e. that their header doesn't directly include). That sometimes works when the exported submodule is in the same module, but when the std mega module is broken up (D144322), some of the exports stop working. Make the exports and includes consistent, either by adding includes for the exports, or by removing exports for missing includes. The concepts.equality_comparable export in std.iterator.__iterator.concepts isn't doing anything because 1) it's resolved as std.iterator.__iterator.concepts.equality_comparable and 2) there's a __concepts submodule in between std.concepts and equality_comparable. Fix it to be std.concepts.__concepts.equality_comparable. <span> is listed in both std.span and std.experimental.span. Delete the latter module. There is no __errc module or header, so remove that export from std.system_error. Reviewed By: ldionne, #libc Differential Revision: https://reviews.llvm.org/D153211 | 2 年前 | |
[libc++][Modules] Make top level modules for all C++ headers with OS/clang versions The headers that include_next compiler and OS headers need to be in different top level modules in order to avoid module cycles. e.g. libc++'s stdlib.h will #include_next stdlib.h from the compiler and then the C library. Either of those are likely to include stddef.h, which will come back up to the libc++ module map and create a module cycle. Putting stdlib.h and stddef.h (and the rest of the C standard library headers) in top level modules resolves this by letting the order go cxx_stdlib_h -> os_stdlib_h -> cxx_stddef_h -> os_stddef_h. All of those headers' dependencies then need to be moved into top level modules themselves to avoid module cycles between the new top level level cstd modules. This starts to get complicated, as the libc++ C headers, by standard, have to include many of the C++ headers, which include the private detail headers, which are intertwined. e.g. some __algorithm headers include __memory headers and vice versa. Make top level modules for all of the libc++ headers to easily guarantee that the modules aren't cyclic. Add enough module exports to fix check-cxx and run-buildbot generic-modules. __stop_token/intrusive_shared_ptr.h uses __atomic/atomic.h but has no include path to it. Add that include. math.h absorbs bits/atomic_wide_counter.h on some platforms that don't have modules, work around that by including math.h in __threading_support. <mutex> doesn't actually require threads, there are a few pieces like once_flag that work without threads. Remove the requirement from its module. AIX is no longer able to support modular builds. Reviewed By: ldionne, #libc Differential Revision: https://reviews.llvm.org/D144322 | 2 年前 | |
[libc++] Merge _LIBCPP_FUNC_VIS, _LIBCPP_TYPE_VIS and _LIBCPP_EXCEPTION_ABI into _LIBCPP_EXPORTED_FROM_ABI These macros are always defined identically, so we can simplify the code a bit by merging them. Reviewed By: ldionne, #libc Spies: libcxx-commits, krytarowski, smeenai Differential Revision: https://reviews.llvm.org/D152652 | 3 年前 | |
[libc++] Fix problems with GCC 13 and switch to it in the CI Reviewed By: #libc, #libc_abi, Mordante Spies: arphaman, Mordante, libcxx-commits, arichardson Differential Revision: https://reviews.llvm.org/D157060 | 2 年前 | |
[libc++] Fix std::pair's pair-like constructor's incorrect assumption (#66585) The helper function __pair_like_explicit_wknd is only SFINAE-ed with tuple_size<remove_cvref_t<_PairLike>>::value == 2, but its function body assumes std::get being valid. Fixes #65620 (cherry picked from commit 054f9c55c6b4520d3feb8b4354b9b942026b5124) | 2 年前 | |
[libc++][NFC] Replace _LIBCPP_STD_VER > x with _LIBCPP_STD_VER >= x This change is almost fully mechanical. The only interesting change is in generate_feature_test_macro_components.py to generate _LIBCPP_STD_VER >= instead. To avoid churn in the git-blame this commit should be added to the .git-blame-ignore-revs once committed. Reviewed By: ldionne, var-const, #libc Spies: jloser, libcxx-commits, arichardson, arphaman, wenlei Differential Revision: https://reviews.llvm.org/D143962 | 3 年前 | |
[libc++] Fix template parameter naming and enforce it through readability-identifier-naming Reviewed By: #libc, Mordante Spies: Mordante, aheejin, libcxx-commits Differential Revision: https://reviews.llvm.org/D156059 | 2 年前 | |
[libc++] Add hide_from_abi check for classes We already have a clang-tidy check for making sure that _LIBCPP_HIDE_FROM_ABI is on free functions. This patch extends this to class members. The places where we don't check for _LIBCPP_HIDE_FROM_ABI are classes for which we have an instantiation in the library. Reviewed By: ldionne, Mordante, #libc Spies: jplehr, mikhail.ramalho, sstefan1, libcxx-commits, krytarowski, miyuki, smeenai Differential Revision: https://reviews.llvm.org/D142332 | 3 年前 | |
[libc++][Modules] Recreate the top level std clang module lldb needs the std clang module to make all of libc++ available in the debugger. Make a new header to include the rest of the public headers and use to build a std module that just re-exports the rest of libc++. Reviewed By: Mordante, JDevlieghere, #libc Differential Revision: https://reviews.llvm.org/D156177 (cherry picked from commit a800485a2deda0807cb9dc212b7d42ac916055fd) | 2 年前 | |
[libc++][hardening] Deprecate _LIBCPP_ENABLE_ASSERTIONS. _LIBCPP_ENABLE_ASSERTIONS was used to enable the "safe" mode in libc++. Libc++ now provides the hardened mode and the debug mode that replace the safe mode. For backward compatibility, enabling _LIBCPP_ENABLE_ASSERTIONS now enables the hardened mode. Note that the hardened mode provides a narrower set of checks than the previous "safe" mode (only security-critical checks that are performant enough to be used in production). Differential Revision: https://reviews.llvm.org/D154997 | 2 年前 | |
[libc++] Add incomplete availability markup for std::pmr This fixes rdar://110330781, which asked for the feature-test macro for std::pmr to take into account the deployment target. It doesn't fix https://llvm.org/PR62212, though, because the availability markup itself must be disabled until some Clang bugs have been fixed. This is pretty vexing, however at least everything should work once those Clang bugs have been fixed. In the meantime, this patch at least adds the required markup (as disabled) and ensures that the feature-test macro for std::pmr is aware of the deployment target requirement. Differential Revision: https://reviews.llvm.org/D135813 | 3 年前 | |
[libc++] Fix template parameter naming and enforce it through readability-identifier-naming Reviewed By: #libc, Mordante Spies: Mordante, aheejin, libcxx-commits Differential Revision: https://reviews.llvm.org/D156059 | 2 年前 | |
Bump version to 17.0.6 | 2 年前 | |
[libc++][hardening] Remove hardening from release notes, undeprecate safe mode This patch effectively maintains the status quo, making sure that the safe mode keeps working the same way as before. Hardening will target the next major release, allowing it to go through RFC and for the implementation to stabilize and mature. Differential Revision: https://reviews.llvm.org/D159171 | 2 年前 | |
[libc++][hardening] Categorize more assertions. Differential Revision: https://reviews.llvm.org/D155873 | 2 年前 | |
[libc++] Add missing includes Those were found while trying to enable configurations like no-threads and no-localization with Clang modules enabled. Differential Revision: https://reviews.llvm.org/D153977 | 2 年前 | |
[libc++] Include "bits/alltypes.h" to provide mbstate_t when using musl libc With D148542, we ran into the following libc++ build error when using musl libc. .../musl/include/bits/alltypes.h:354:16: error: definition of type '__mbstate_t' conflicts with typedef of the same name typedef struct __mbstate_t { unsigned __opaque1, __opaque2; } mbstate_t; ^ .../sysroot/usr/include/bits/types/__mbstate_t.h:21:3: note: '__mbstate_t' declared here } __mbstate_t; ^ 1 error generated. This is because the mbstate_t definition in musl libc conflicts with the one from "bits/types/mbstate_t.h", and this patch attempts to fix this build issue when musl libc is used. Reviewed By: iana Differential Revision: https://reviews.llvm.org/D151740 | 3 年前 | |
[libc++][hardening] Categorize more assertions. Differential Revision: https://reviews.llvm.org/D155873 | 2 年前 | |
[libc++][PSTL] Copy the headers into libc++ We decided to integrate the PSTL into our own headers and only share the backend impletementations. This is a first step in that direction, specifically it copies the PSTL headers into the libc++ structure. Reviewed By: ldionne, #libc Spies: rodgert, mikhail.ramalho, jplehr, bcain, h-vetinari, Mordante, rarutyun, var-const, sstefan1, pcwang-thead, libcxx-commits, arichardson, mgrang, miyuki Differential Revision: https://reviews.llvm.org/D141779 | 3 年前 | |
[libc++][PSTL] Copy the headers into libc++ We decided to integrate the PSTL into our own headers and only share the backend impletementations. This is a first step in that direction, specifically it copies the PSTL headers into the libc++ structure. Reviewed By: ldionne, #libc Spies: rodgert, mikhail.ramalho, jplehr, bcain, h-vetinari, Mordante, rarutyun, var-const, sstefan1, pcwang-thead, libcxx-commits, arichardson, mgrang, miyuki Differential Revision: https://reviews.llvm.org/D141779 | 3 年前 | |
[libc++][PSTL] Copy the headers into libc++ We decided to integrate the PSTL into our own headers and only share the backend impletementations. This is a first step in that direction, specifically it copies the PSTL headers into the libc++ structure. Reviewed By: ldionne, #libc Spies: rodgert, mikhail.ramalho, jplehr, bcain, h-vetinari, Mordante, rarutyun, var-const, sstefan1, pcwang-thead, libcxx-commits, arichardson, mgrang, miyuki Differential Revision: https://reviews.llvm.org/D141779 | 3 年前 | |
[libc++][PSTL] Copy the headers into libc++ We decided to integrate the PSTL into our own headers and only share the backend impletementations. This is a first step in that direction, specifically it copies the PSTL headers into the libc++ structure. Reviewed By: ldionne, #libc Spies: rodgert, mikhail.ramalho, jplehr, bcain, h-vetinari, Mordante, rarutyun, var-const, sstefan1, pcwang-thead, libcxx-commits, arichardson, mgrang, miyuki Differential Revision: https://reviews.llvm.org/D141779 | 3 年前 | |
[libc++][NFC] Rename iterator category checks to make it obvious that they check //only// the iterator category We plan to add concepts for checking that iterators actually provide what they claim to. This is to avoid people thinking that these type traits actually check the iterator requirements in more detail. Reviewed By: ldionne, #libc Spies: Mordante, libcxx-commits, wenlei Differential Revision: https://reviews.llvm.org/D150801 | 3 年前 | |
[libc++][Modules] Simplify the __std_clang_module header generation Post review feedback on D157364. Don't section the __std_clang_module header by macro, put the headers in alphabetical order and repeat the macro guards. Restore header_information.header_restrictions. Reviewed By: ldionne, #libc Differential Revision: https://reviews.llvm.org/D158133 # Conflicts: # libcxx/utils/libcxx/header_information.py | 2 年前 | |
[libc++] cuchar redeclares ::mbstate_t when it's in its own clang module When cuchar is compiled independently on platforms that don't have <uchar.h>, it doesn't get a declaration of mbstate_t, and so makes an empty declaration for ::mbstate_t. That conflicts with the declarations in __mbstate_t.h and cwchar since both of those headers do get mbstate_t before making ::mbstate_t. Change __mbstate_t.h to just get the underlying declaration for mbstate_t and not make a declaration for ::mbstate_t. Include __mbstate_t.h in uchar.h and wchar.h when their next headers aren't available so that at least mbstate_t gets defined. Add __std_mbstate_t.h to declare ::mbstate_t for headers that need that when cuchar or cwchar aren't available (because either _LIBCPP_HAS_NO_WIDE_CHARACTERS or _LIBCPP_CXX03_LANG). Reviewed By: ldionne, Mordante, #libc, philnik Differential Revision: https://reviews.llvm.org/D148542 | 3 年前 | |
[libc++][Modules] Make top level modules for all C++ headers with OS/clang versions The headers that include_next compiler and OS headers need to be in different top level modules in order to avoid module cycles. e.g. libc++'s stdlib.h will #include_next stdlib.h from the compiler and then the C library. Either of those are likely to include stddef.h, which will come back up to the libc++ module map and create a module cycle. Putting stdlib.h and stddef.h (and the rest of the C standard library headers) in top level modules resolves this by letting the order go cxx_stdlib_h -> os_stdlib_h -> cxx_stddef_h -> os_stddef_h. All of those headers' dependencies then need to be moved into top level modules themselves to avoid module cycles between the new top level level cstd modules. This starts to get complicated, as the libc++ C headers, by standard, have to include many of the C++ headers, which include the private detail headers, which are intertwined. e.g. some __algorithm headers include __memory headers and vice versa. Make top level modules for all of the libc++ headers to easily guarantee that the modules aren't cyclic. Add enough module exports to fix check-cxx and run-buildbot generic-modules. __stop_token/intrusive_shared_ptr.h uses __atomic/atomic.h but has no include path to it. Add that include. math.h absorbs bits/atomic_wide_counter.h on some platforms that don't have modules, work around that by including math.h in __threading_support. <mutex> doesn't actually require threads, there are a few pieces like once_flag that work without threads. Remove the requirement from its module. AIX is no longer able to support modular builds. Reviewed By: ldionne, #libc Differential Revision: https://reviews.llvm.org/D144322 | 2 年前 | |
[libc++][hardening] Categorize more assertions. Differential Revision: https://reviews.llvm.org/D155873 | 2 年前 | |
Fixing conflicting macro definitions between curses.h and the standard library. POSIX allows certain macros to exist with generic names (i.e. refresh(), move(), and erase()) to exist in curses.h which conflict with functions found in std::filesystem, among others. This patch undefs the macros in question and adds them to LIBCPP_PUSH_MACROS and LIBCPP_POP_MACROS. Reviewed By: #libc, philnik, ldionne Differential Revision: https://reviews.llvm.org/D147356 | 2 年前 | |
[libc++] Fix __verbose_abort in C++11 __use() can't be marked as constexpr in C++11 because it returns void, which is not a literal type. But it turns out that we just don't need to define it at all, since it's never called outside of decltype. Differential Revision: https://reviews.llvm.org/D149360 | 3 年前 | |
[libc++][PSTL] Implement std::sort Reviewed By: #libc, ldionne Spies: ldionne, libcxx-commits, mgrang Differential Revision: https://reviews.llvm.org/D152860 | 2 年前 | |
Fixing conflicting macro definitions between curses.h and the standard library. POSIX allows certain macros to exist with generic names (i.e. refresh(), move(), and erase()) to exist in curses.h which conflict with functions found in std::filesystem, among others. This patch undefs the macros in question and adds them to LIBCPP_PUSH_MACROS and LIBCPP_POP_MACROS. Reviewed By: #libc, philnik, ldionne Differential Revision: https://reviews.llvm.org/D147356 | 2 年前 | |
[libc++][hardening] Categorize most assertions inside the container classes. This introduces: - _LIBCPP_ASSERT_VALID_INPUT_RANGE; - _LIBCPP_ASSERT_VALID_CONTAINER_ACCESS; - _LIBCPP_ASSERT_VALID_ITERATOR_ACCESS; - _LIBCPP_ASSERT_VALID_ALLOCATOR; - _LIBCPP_ASSERT_INTERNAL. Differential Revision: https://reviews.llvm.org/D155349 | 2 年前 | |
[libc++] Granularize <atomic> includes Reviewed By: ldionne, Mordante, #libc Spies: arichardson, libcxx-commits Differential Revision: https://reviews.llvm.org/D144255 | 3 年前 | |
[libc++] add basic runtime assertions to <barrier> Adding assertions will aid users that have bugs in their code to receive better error messages. Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D154626 | 2 年前 | |
[libc++] Remove <cstdlib> includes We changed the abort calls when trying to throw exceptions in -fno-exceptions mode to __verbose_abort calls, which removes the dependency in most files. Reviewed By: ldionne, #libc Spies: dim, emaste, mikhail.ramalho, smeenai, libcxx-commits Differential Revision: https://reviews.llvm.org/D146076 | 3 年前 | |
[NFC][libc++][bitset] Refactors constructors. Based on the review comments in D153201 this combines the string and c-string constructors. The common constructor is using a string_view: - it allows propagating the _Traits, which are required to be used for comparison. - it avoids allocating - libc++ supports it in C++03 Reviewed By: philnik, #libc, ldionne Differential Revision: https://reviews.llvm.org/D154860 | 2 年前 | |
[libc++] Add missing __has_include checks for C headers not provided by libc++ This makes the library consistent in how it handles C library headers. For C headers provided by libc++, we unconditionally include <foo.h> from <cfoo>, and then <foo.h> conditionally include_next <foo.h>. For headers not provided by libc++, <cfoo> conditionally includes the system's <foo.h> directly. Differential Revision: https://reviews.llvm.org/D138512 | 3 年前 | |
[libc++] Ensure that all public C++ headers include <__assert> This patch changes the requirement for getting the declaration of the assertion handler from including <__assert> to including any public C++ header of the library. Note that C compatibility headers are excluded because we don't implement all the C headers ourselves -- some of them are taken straight from the C library, like assert.h. It also adds a generated test to check it. Furthermore, this new generated test is designed in a way that will make it possible to replace almost all the existing test-generation scripts with this system in upcoming patches. Differential Revision: https://reviews.llvm.org/D122506 | 4 年前 | |
[libc++] Diagnose when header search paths are set up incorrectly An issue I often see in codebases compiled for unusual platforms is that header search paths are specified manually and are subtly wrong. For example, people will manually add -isystem <some-toolchain>/usr/include, which ends up messing up the layering of header search paths required by libc++ (because the C Standard Library now appears *before* libc++ in the search paths). Without this patch, this will end up causing compilation errors that are pretty inscrutable. This patch aims to improve the user experience by diagnosing this issue explicitly. In all cases I can think of, I would expect that a compilation error occur if these header search paths are not layered properly. This should only provide an explicit diagnostic instead of failing due to seemingly unrelated compilation errors. Differential Revision: https://reviews.llvm.org/D131441 | 3 年前 | |
[libc++] Diagnose when header search paths are set up incorrectly An issue I often see in codebases compiled for unusual platforms is that header search paths are specified manually and are subtly wrong. For example, people will manually add -isystem <some-toolchain>/usr/include, which ends up messing up the layering of header search paths required by libc++ (because the C Standard Library now appears *before* libc++ in the search paths). Without this patch, this will end up causing compilation errors that are pretty inscrutable. This patch aims to improve the user experience by diagnosing this issue explicitly. In all cases I can think of, I would expect that a compilation error occur if these header search paths are not layered properly. This should only provide an explicit diagnostic instead of failing due to seemingly unrelated compilation errors. Differential Revision: https://reviews.llvm.org/D131441 | 3 年前 | |
[libc++] Diagnose when header search paths are set up incorrectly An issue I often see in codebases compiled for unusual platforms is that header search paths are specified manually and are subtly wrong. For example, people will manually add -isystem <some-toolchain>/usr/include, which ends up messing up the layering of header search paths required by libc++ (because the C Standard Library now appears *before* libc++ in the search paths). Without this patch, this will end up causing compilation errors that are pretty inscrutable. This patch aims to improve the user experience by diagnosing this issue explicitly. In all cases I can think of, I would expect that a compilation error occur if these header search paths are not layered properly. This should only provide an explicit diagnostic instead of failing due to seemingly unrelated compilation errors. Differential Revision: https://reviews.llvm.org/D131441 | 3 年前 | |
[libc++] Diagnose when header search paths are set up incorrectly An issue I often see in codebases compiled for unusual platforms is that header search paths are specified manually and are subtly wrong. For example, people will manually add -isystem <some-toolchain>/usr/include, which ends up messing up the layering of header search paths required by libc++ (because the C Standard Library now appears *before* libc++ in the search paths). Without this patch, this will end up causing compilation errors that are pretty inscrutable. This patch aims to improve the user experience by diagnosing this issue explicitly. In all cases I can think of, I would expect that a compilation error occur if these header search paths are not layered properly. This should only provide an explicit diagnostic instead of failing due to seemingly unrelated compilation errors. Differential Revision: https://reviews.llvm.org/D131441 | 3 年前 | |
[libc++] Remove the legacy debug mode. See https://discourse.llvm.org/t/rfc-removing-the-legacy-debug-mode-from-libc/71026 Reviewed By: #libc, Mordante, ldionne Differential Revision: https://reviews.llvm.org/D153672 | 2 年前 | |
[libc++][spaceship] P1614R2: Removed operator!= from weekdays Implements parts of P1614R2. Removed operator!= from: - weekday - weekday_indexed - weekday_last - month_weekday - month_weekday_last - year_month_weekday - year_month_weekday_last Note these operators were added and removed in C++20. Reviewed By: #libc, Mordante Differential Revision: https://reviews.llvm.org/D152699 | 3 年前 | |
[libc++][NFC] Fix some standard-mandated includes comments Reviewed By: ldionne, #libc Spies: libcxx-commits Differential Revision: https://reviews.llvm.org/D134447 | 3 年前 | |
[libc++] Ensure that all public C++ headers include <__assert> This patch changes the requirement for getting the declaration of the assertion handler from including <__assert> to including any public C++ header of the library. Note that C compatibility headers are excluded because we don't implement all the C headers ourselves -- some of them are taken straight from the C library, like assert.h. It also adds a generated test to check it. Furthermore, this new generated test is designed in a way that will make it possible to replace almost all the existing test-generation scripts with this system in upcoming patches. Differential Revision: https://reviews.llvm.org/D122506 | 4 年前 | |
[libc++] Diagnose when header search paths are set up incorrectly An issue I often see in codebases compiled for unusual platforms is that header search paths are specified manually and are subtly wrong. For example, people will manually add -isystem <some-toolchain>/usr/include, which ends up messing up the layering of header search paths required by libc++ (because the C Standard Library now appears *before* libc++ in the search paths). Without this patch, this will end up causing compilation errors that are pretty inscrutable. This patch aims to improve the user experience by diagnosing this issue explicitly. In all cases I can think of, I would expect that a compilation error occur if these header search paths are not layered properly. This should only provide an explicit diagnostic instead of failing due to seemingly unrelated compilation errors. Differential Revision: https://reviews.llvm.org/D131441 | 3 年前 | |
[libc++] Diagnose when header search paths are set up incorrectly An issue I often see in codebases compiled for unusual platforms is that header search paths are specified manually and are subtly wrong. For example, people will manually add -isystem <some-toolchain>/usr/include, which ends up messing up the layering of header search paths required by libc++ (because the C Standard Library now appears *before* libc++ in the search paths). Without this patch, this will end up causing compilation errors that are pretty inscrutable. This patch aims to improve the user experience by diagnosing this issue explicitly. In all cases I can think of, I would expect that a compilation error occur if these header search paths are not layered properly. This should only provide an explicit diagnostic instead of failing due to seemingly unrelated compilation errors. Differential Revision: https://reviews.llvm.org/D131441 | 3 年前 | |
[libc++][NFC] Replace _LIBCPP_STD_VER > x with _LIBCPP_STD_VER >= x This change is almost fully mechanical. The only interesting change is in generate_feature_test_macro_components.py to generate _LIBCPP_STD_VER >= instead. To avoid churn in the git-blame this commit should be added to the .git-blame-ignore-revs once committed. Reviewed By: ldionne, var-const, #libc Spies: jloser, libcxx-commits, arichardson, arphaman, wenlei Differential Revision: https://reviews.llvm.org/D143962 | 3 年前 | |
[libc++] Merge _LIBCPP_FUNC_VIS, _LIBCPP_TYPE_VIS and _LIBCPP_EXCEPTION_ABI into _LIBCPP_EXPORTED_FROM_ABI These macros are always defined identically, so we can simplify the code a bit by merging them. Reviewed By: ldionne, #libc Spies: libcxx-commits, krytarowski, smeenai Differential Revision: https://reviews.llvm.org/D152652 | 3 年前 | |
[libc++] Module fixes for __synth_three_way. These changes make it possible to use __synth_three_way in modules. The change from a lambda to a function is a Clang issue. The change is list was needed since the compiler couldn't deduce the comparison template argument. Adds a few missing includes too. Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D146545 | 3 年前 | |
[libc++][spaceship] P1614R2: Removed ops from complex Implements parts of P1614R2: - Removed ops from complex Reviewed By: #libc, Mordante Differential Revision: https://reviews.llvm.org/D152615 | 3 年前 | |
[libc++] Only include_next C library headers when they exist Some platforms don't provide all C library headers. In practice, libc++ only requires a few C library headers to exist, and only a few functions on those headers. Missing functions that libc++ doesn't need for its own implementation are handled properly by the using_if_exists attribute, however a missing header is currently a hard error when we try to do #include_next. This patch should make libc++ more flexible on platforms that do not provide C headers that libc++ doesn't actually require for its own implementation. The only downside is that it may move some errors from the #include_next point to later in the compilation if we actually try to use something that isn't provided, which could be somewhat confusing. However, these errors should be caught by folks trying to port libc++ over to a new platform (when running the libc++ test suite), not by end users. NOTE: This is a reapplicaton of 226409, which was reverted in 674729813 because it broke the build. The issue has now been fixed with https://reviews.llvm.org/D138062. Differential Revision: https://reviews.llvm.org/D136683 | 3 年前 | |
[libc++] Granularize <type_traits> includes in <concepts> Reviewed By: ldionne, Mordante, #libc Spies: jloser, libcxx-commits Differential Revision: https://reviews.llvm.org/D139189 | 3 年前 | |
[libc++] Merge _LIBCPP_FUNC_VIS, _LIBCPP_TYPE_VIS and _LIBCPP_EXCEPTION_ABI into _LIBCPP_EXPORTED_FROM_ABI These macros are always defined identically, so we can simplify the code a bit by merging them. Reviewed By: ldionne, #libc Spies: libcxx-commits, krytarowski, smeenai Differential Revision: https://reviews.llvm.org/D152652 | 3 年前 | |
[libc++] Granularize <type_traits> includes in <bit>, <numbers> and <coroutine> <coroutine> seems to be new enough to not be a huge problem. Reviewed By: Mordante, #libc Spies: libcxx-commits, ChuanqiXu Differential Revision: https://reviews.llvm.org/D140600 | 3 年前 | |
[libc++] Diagnose when header search paths are set up incorrectly An issue I often see in codebases compiled for unusual platforms is that header search paths are specified manually and are subtly wrong. For example, people will manually add -isystem <some-toolchain>/usr/include, which ends up messing up the layering of header search paths required by libc++ (because the C Standard Library now appears *before* libc++ in the search paths). Without this patch, this will end up causing compilation errors that are pretty inscrutable. This patch aims to improve the user experience by diagnosing this issue explicitly. In all cases I can think of, I would expect that a compilation error occur if these header search paths are not layered properly. This should only provide an explicit diagnostic instead of failing due to seemingly unrelated compilation errors. Differential Revision: https://reviews.llvm.org/D131441 | 3 年前 | |
[libc++] Add missing __has_include checks for C headers not provided by libc++ This makes the library consistent in how it handles C library headers. For C headers provided by libc++, we unconditionally include <foo.h> from <cfoo>, and then <foo.h> conditionally include_next <foo.h>. For headers not provided by libc++, <cfoo> conditionally includes the system's <foo.h> directly. Differential Revision: https://reviews.llvm.org/D138512 | 3 年前 | |
[libc++] Add missing __has_include checks for C headers not provided by libc++ This makes the library consistent in how it handles C library headers. For C headers provided by libc++, we unconditionally include <foo.h> from <cfoo>, and then <foo.h> conditionally include_next <foo.h>. For headers not provided by libc++, <cfoo> conditionally includes the system's <foo.h> directly. Differential Revision: https://reviews.llvm.org/D138512 | 3 年前 | |
[libc++] Ensure that all public C++ headers include <__assert> This patch changes the requirement for getting the declaration of the assertion handler from including <__assert> to including any public C++ header of the library. Note that C compatibility headers are excluded because we don't implement all the C headers ourselves -- some of them are taken straight from the C library, like assert.h. It also adds a generated test to check it. Furthermore, this new generated test is designed in a way that will make it possible to replace almost all the existing test-generation scripts with this system in upcoming patches. Differential Revision: https://reviews.llvm.org/D122506 | 4 年前 | |
[libc++][NFC] Replace _LIBCPP_STD_VER > x with _LIBCPP_STD_VER >= x This change is almost fully mechanical. The only interesting change is in generate_feature_test_macro_components.py to generate _LIBCPP_STD_VER >= instead. To avoid churn in the git-blame this commit should be added to the .git-blame-ignore-revs once committed. Reviewed By: ldionne, var-const, #libc Spies: jloser, libcxx-commits, arichardson, arphaman, wenlei Differential Revision: https://reviews.llvm.org/D143962 | 3 年前 | |
[libc++] Diagnose when header search paths are set up incorrectly An issue I often see in codebases compiled for unusual platforms is that header search paths are specified manually and are subtly wrong. For example, people will manually add -isystem <some-toolchain>/usr/include, which ends up messing up the layering of header search paths required by libc++ (because the C Standard Library now appears *before* libc++ in the search paths). Without this patch, this will end up causing compilation errors that are pretty inscrutable. This patch aims to improve the user experience by diagnosing this issue explicitly. In all cases I can think of, I would expect that a compilation error occur if these header search paths are not layered properly. This should only provide an explicit diagnostic instead of failing due to seemingly unrelated compilation errors. Differential Revision: https://reviews.llvm.org/D131441 | 3 年前 | |
[libc++] Diagnose when header search paths are set up incorrectly An issue I often see in codebases compiled for unusual platforms is that header search paths are specified manually and are subtly wrong. For example, people will manually add -isystem <some-toolchain>/usr/include, which ends up messing up the layering of header search paths required by libc++ (because the C Standard Library now appears *before* libc++ in the search paths). Without this patch, this will end up causing compilation errors that are pretty inscrutable. This patch aims to improve the user experience by diagnosing this issue explicitly. In all cases I can think of, I would expect that a compilation error occur if these header search paths are not layered properly. This should only provide an explicit diagnostic instead of failing due to seemingly unrelated compilation errors. Differential Revision: https://reviews.llvm.org/D131441 | 3 年前 | |
[libc++][NFC] Replace _LIBCPP_STD_VER > x with _LIBCPP_STD_VER >= x This change is almost fully mechanical. The only interesting change is in generate_feature_test_macro_components.py to generate _LIBCPP_STD_VER >= instead. To avoid churn in the git-blame this commit should be added to the .git-blame-ignore-revs once committed. Reviewed By: ldionne, var-const, #libc Spies: jloser, libcxx-commits, arichardson, arphaman, wenlei Differential Revision: https://reviews.llvm.org/D143962 | 3 年前 | |
[libc++] Move constexpr <cstring> functions into their own headers and remove unused <cstring> includes Reviewed By: ldionne, Mordante, #libc, #libc_abi Spies: libcxx-commits Differential Revision: https://reviews.llvm.org/D143329 | 3 年前 | |
[libc++] Ensure that all public C++ headers include <__assert> This patch changes the requirement for getting the declaration of the assertion handler from including <__assert> to including any public C++ header of the library. Note that C compatibility headers are excluded because we don't implement all the C headers ourselves -- some of them are taken straight from the C library, like assert.h. It also adds a generated test to check it. Furthermore, this new generated test is designed in a way that will make it possible to replace almost all the existing test-generation scripts with this system in upcoming patches. Differential Revision: https://reviews.llvm.org/D122506 | 4 年前 | |
[libc++][NFC] Replace _LIBCPP_STD_VER > x with _LIBCPP_STD_VER >= x This change is almost fully mechanical. The only interesting change is in generate_feature_test_macro_components.py to generate _LIBCPP_STD_VER >= instead. To avoid churn in the git-blame this commit should be added to the .git-blame-ignore-revs once committed. Reviewed By: ldionne, var-const, #libc Spies: jloser, libcxx-commits, arichardson, arphaman, wenlei Differential Revision: https://reviews.llvm.org/D143962 | 3 年前 | |
[libc++] Only include_next C library headers when they exist Some platforms don't provide all C library headers. In practice, libc++ only requires a few C library headers to exist, and only a few functions on those headers. Missing functions that libc++ doesn't need for its own implementation are handled properly by the using_if_exists attribute, however a missing header is currently a hard error when we try to do #include_next. This patch should make libc++ more flexible on platforms that do not provide C headers that libc++ doesn't actually require for its own implementation. The only downside is that it may move some errors from the #include_next point to later in the compilation if we actually try to use something that isn't provided, which could be somewhat confusing. However, these errors should be caught by folks trying to port libc++ over to a new platform (when running the libc++ test suite), not by end users. NOTE: This is a reapplicaton of 226409, which was reverted in 674729813 because it broke the build. The issue has now been fixed with https://reviews.llvm.org/D138062. Differential Revision: https://reviews.llvm.org/D136683 | 3 年前 | |
[libc++][cuchar] Declare std::c8rtomb and std::mbrtoc8 in <cuchar> if available. This change implements the C library dependent portions of P0482R6 (char8_t: A type for UTF-8 characters and strings (Revision 6)) by declaring std::c8rtomb() and std::mbrtoc8() in the <cuchar> header when implementations are provided by the C library as specified by WG14 N2653 (char8_t: A type for UTF-8 characters and strings (Revision 1)) as adopted for C23. A _LIBCPP_HAS_NO_C8RTOMB_MBRTOC8 macro is defined by the libc++ __config header unless it is known that the C library provides these functions in the current compilation mode. This macro is used for testing purposes and may be of use to libc++ users. At present, the only C library known to implement these functions is GNU libc as of its 2.36 release. Reviewed By: ldionne Differential Revision: https://reviews.llvm.org/D130946 | 3 年前 | |
[libc++] Forward to std::{,w}memchr in std::find Reviewed By: #libc, ldionne Spies: Mordante, libcxx-commits, ldionne, mikhail.ramalho Differential Revision: https://reviews.llvm.org/D144394 | 3 年前 | |
[libc++] Diagnose when header search paths are set up incorrectly An issue I often see in codebases compiled for unusual platforms is that header search paths are specified manually and are subtly wrong. For example, people will manually add -isystem <some-toolchain>/usr/include, which ends up messing up the layering of header search paths required by libc++ (because the C Standard Library now appears *before* libc++ in the search paths). Without this patch, this will end up causing compilation errors that are pretty inscrutable. This patch aims to improve the user experience by diagnosing this issue explicitly. In all cases I can think of, I would expect that a compilation error occur if these header search paths are not layered properly. This should only provide an explicit diagnostic instead of failing due to seemingly unrelated compilation errors. Differential Revision: https://reviews.llvm.org/D131441 | 3 年前 | |
[NFC][libc++] Update comments to reflect changes in ASan ASan capabilities were extended, but some comments were not updated and describe old behavior. This commit updates outdated comments, which I found. Mentioned changes are: - All allocators in containers ( std::vector and std::deque; D146815 D136765) are supported, but it's possible to turn off annotations for a specific allocator (D145628). - Buffers don't have to be aligned (D132522). Reviewed By: #libc, philnik Differential Revision: https://reviews.llvm.org/D156155 | 2 年前 | |
[libc++] Only include_next C library headers when they exist Some platforms don't provide all C library headers. In practice, libc++ only requires a few C library headers to exist, and only a few functions on those headers. Missing functions that libc++ doesn't need for its own implementation are handled properly by the using_if_exists attribute, however a missing header is currently a hard error when we try to do #include_next. This patch should make libc++ more flexible on platforms that do not provide C headers that libc++ doesn't actually require for its own implementation. The only downside is that it may move some errors from the #include_next point to later in the compilation if we actually try to use something that isn't provided, which could be somewhat confusing. However, these errors should be caught by folks trying to port libc++ over to a new platform (when running the libc++ test suite), not by end users. NOTE: This is a reapplicaton of 226409, which was reverted in 674729813 because it broke the build. The issue has now been fixed with https://reviews.llvm.org/D138062. Differential Revision: https://reviews.llvm.org/D136683 | 3 年前 | |
[libc++] Granularize <exception> This patch also updates the moved code to the new style (i.e. formatted, replaced marcos and typedefs) Reviewed By: ldionne, #libc Spies: arichardson, libcxx-commits Differential Revision: https://reviews.llvm.org/D145095 | 3 年前 | |
[libc++][PSTL] Add more specialized backend customization points This allows backends to customize arbitrary parallel algorithms, which was requested pretty often. Reviewed By: #libc, ldionne Spies: arichardson, miyuki, crtrott, dalg24, __simt__, philnik, libcxx-commits Differential Revision: https://reviews.llvm.org/D149686 | 3 年前 | |
[libc++] Implement std::expected P0323R12 Implement std::expected https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p0323r12.html Added tests Differential Revision: https://reviews.llvm.org/D124516 address comment | 3 年前 | |
[libc++] Only include_next C library headers when they exist Some platforms don't provide all C library headers. In practice, libc++ only requires a few C library headers to exist, and only a few functions on those headers. Missing functions that libc++ doesn't need for its own implementation are handled properly by the using_if_exists attribute, however a missing header is currently a hard error when we try to do #include_next. This patch should make libc++ more flexible on platforms that do not provide C headers that libc++ doesn't actually require for its own implementation. The only downside is that it may move some errors from the #include_next point to later in the compilation if we actually try to use something that isn't provided, which could be somewhat confusing. However, these errors should be caught by folks trying to port libc++ over to a new platform (when running the libc++ test suite), not by end users. NOTE: This is a reapplicaton of 226409, which was reverted in 674729813 because it broke the build. The issue has now been fixed with https://reviews.llvm.org/D138062. Differential Revision: https://reviews.llvm.org/D136683 | 3 年前 | |
[libc++] Expand the contents of LIBCXX_ENABLE_FILESYSTEM Since LIBCXX_ENABLE_FILESYSTEM now truly represents whether the platform supports a filesystem (as opposed to whether the <filesystem> library is provided), we can provide a few additional classes from the <filesystem> library even when the platform does not have support for a filesystem. For example, this allows performing path manipulations using std::filesystem::path even on platforms where there is no actual filesystem. rdar://107061236 Differential Revision: https://reviews.llvm.org/D152382 | 2 年前 | |
[libc++] Only include_next C library headers when they exist Some platforms don't provide all C library headers. In practice, libc++ only requires a few C library headers to exist, and only a few functions on those headers. Missing functions that libc++ doesn't need for its own implementation are handled properly by the using_if_exists attribute, however a missing header is currently a hard error when we try to do #include_next. This patch should make libc++ more flexible on platforms that do not provide C headers that libc++ doesn't actually require for its own implementation. The only downside is that it may move some errors from the #include_next point to later in the compilation if we actually try to use something that isn't provided, which could be somewhat confusing. However, these errors should be caught by folks trying to port libc++ over to a new platform (when running the libc++ test suite), not by end users. NOTE: This is a reapplicaton of 226409, which was reverted in 674729813 because it broke the build. The issue has now been fixed with https://reviews.llvm.org/D138062. Differential Revision: https://reviews.llvm.org/D136683 | 3 年前 | |
[libc++][format] Removes the experimental status. The code has been quite ready for a while now and there are no more ABI breaking papers. So this is a good time to mark the feature as stable. Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D150802 | 3 年前 | |
[libc++][ranges] Implement the changes to node-based containers 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/D149830 | 2 年前 | |
[libc++][hardening][NFC] Introduce _LIBCPP_ASSERT_UNCATEGORIZED. Replace most uses of _LIBCPP_ASSERT with _LIBCPP_ASSERT_UNCATEGORIZED. This is done as a prerequisite to introducing hardened mode to libc++. The idea is to make enabling assertions an opt-in with (somewhat) fine-grained controls over which categories of assertions are enabled. The vast majority of assertions are currently uncategorized; the new macro will allow turning on _LIBCPP_ASSERT (the underlying mechanism for all kinds of assertions) without enabling all the uncategorized assertions (in the future; this patch preserves the current behavior). Differential Revision: https://reviews.llvm.org/D153816 | 2 年前 | |
[libc++] Remove the legacy debug mode. See https://discourse.llvm.org/t/rfc-removing-the-legacy-debug-mode-from-libc/71026 Reviewed By: #libc, Mordante, ldionne Differential Revision: https://reviews.llvm.org/D153672 | 2 年前 | |
[libc++][hardening][NFC] Introduce _LIBCPP_ASSERT_UNCATEGORIZED. Replace most uses of _LIBCPP_ASSERT with _LIBCPP_ASSERT_UNCATEGORIZED. This is done as a prerequisite to introducing hardened mode to libc++. The idea is to make enabling assertions an opt-in with (somewhat) fine-grained controls over which categories of assertions are enabled. The vast majority of assertions are currently uncategorized; the new macro will allow turning on _LIBCPP_ASSERT (the underlying mechanism for all kinds of assertions) without enabling all the uncategorized assertions (in the future; this patch preserves the current behavior). Differential Revision: https://reviews.llvm.org/D153816 | 2 年前 | |
[libc++][NFC] Rename the constexpr macros This was discussed on Discord with the consensus that we should rename the macros. Reviewed By: ldionne, Mordante, var-const, avogelsgesang, jloser, #libc Spies: libcxx-commits Differential Revision: https://reviews.llvm.org/D131498 | 3 年前 | |
[libc++] Only include_next C library headers when they exist Some platforms don't provide all C library headers. In practice, libc++ only requires a few C library headers to exist, and only a few functions on those headers. Missing functions that libc++ doesn't need for its own implementation are handled properly by the using_if_exists attribute, however a missing header is currently a hard error when we try to do #include_next. This patch should make libc++ more flexible on platforms that do not provide C headers that libc++ doesn't actually require for its own implementation. The only downside is that it may move some errors from the #include_next point to later in the compilation if we actually try to use something that isn't provided, which could be somewhat confusing. However, these errors should be caught by folks trying to port libc++ over to a new platform (when running the libc++ test suite), not by end users. NOTE: This is a reapplicaton of 226409, which was reverted in 674729813 because it broke the build. The issue has now been fixed with https://reviews.llvm.org/D138062. Differential Revision: https://reviews.llvm.org/D136683 | 3 年前 | |
[libc++] Add clang-tidy check for version checks This check flags code which uses _LIBCPP_STD_VER the wrong way, or tries to use __cplusplus. It flags cases where we use _LIBCPP_STD_VER > instead of _LIBCPP_STD_VER >= and where wrong values are used (e.g. _LIBCPP_STD_VER >= 24). Reviewed By: ldionne, #libc Spies: libcxx-commits Differential Revision: https://reviews.llvm.org/D144261 | 3 年前 | |
[libc++] Merge _LIBCPP_FUNC_VIS, _LIBCPP_TYPE_VIS and _LIBCPP_EXCEPTION_ABI into _LIBCPP_EXPORTED_FROM_ABI These macros are always defined identically, so we can simplify the code a bit by merging them. Reviewed By: ldionne, #libc Spies: libcxx-commits, krytarowski, smeenai Differential Revision: https://reviews.llvm.org/D152652 | 3 年前 | |
[libc++] Merge _LIBCPP_FUNC_VIS, _LIBCPP_TYPE_VIS and _LIBCPP_EXCEPTION_ABI into _LIBCPP_EXPORTED_FROM_ABI These macros are always defined identically, so we can simplify the code a bit by merging them. Reviewed By: ldionne, #libc Spies: libcxx-commits, krytarowski, smeenai Differential Revision: https://reviews.llvm.org/D152652 | 3 年前 | |
[libc++] Merge _LIBCPP_FUNC_VIS, _LIBCPP_TYPE_VIS and _LIBCPP_EXCEPTION_ABI into _LIBCPP_EXPORTED_FROM_ABI These macros are always defined identically, so we can simplify the code a bit by merging them. Reviewed By: ldionne, #libc Spies: libcxx-commits, krytarowski, smeenai Differential Revision: https://reviews.llvm.org/D152652 | 3 年前 | |
Revert "[libc++] Apply _LIBCPP_EXCLUDE_FROM_EXPLICIT_INSTANTIATION only in classes that we have instantiated externally" This reverts commit b3c9150062dc4264afb4a3d2790f071c1ebe0743. There were unexpected breakages downstream. @EricWF is investigating. | 3 年前 | |
[libc++] Remove the legacy debug mode. See https://discourse.llvm.org/t/rfc-removing-the-legacy-debug-mode-from-libc/71026 Reviewed By: #libc, Mordante, ldionne Differential Revision: https://reviews.llvm.org/D153672 | 2 年前 | |
[libc++] add basic runtime assertions to <latch> Adding assertions will aid users that have bugs in their code to receive better error messages. Differential Revision: https://reviews.llvm.org/D154425 | 2 年前 | |
[libc++] Utilities for implementing stop_token This change contains three util classes that were out from D145183 to make incremental progress - automic_unique_lock - intrusive_list - intrusive_shared_ptr Differential Revision: https://reviews.llvm.org/D150205 | 3 年前 | |
Revert "[libc++] Remove the type_traits includes from limits and new" type_traits doesn't need to include __type_traits/noexcept_move_assign_container.h, so there is no include cycle from <limits> or <new>. Restore their includes of type_traits to preserve compatibility. This reverts commit 2af6d79c7e38675a184280a2d6a92550702581f7. Reviewed By: ldionne, #libc Differential Revision: https://reviews.llvm.org/D154747 | 2 年前 | |
[libc++] Don't workaround GCC issue on non-GCC compilers Differential Revision: https://reviews.llvm.org/D138438 | 3 年前 | |
[libc++][hardening] Categorize most assertions inside the container classes. This introduces: - _LIBCPP_ASSERT_VALID_INPUT_RANGE; - _LIBCPP_ASSERT_VALID_CONTAINER_ACCESS; - _LIBCPP_ASSERT_VALID_ITERATOR_ACCESS; - _LIBCPP_ASSERT_VALID_ALLOCATOR; - _LIBCPP_ASSERT_INTERNAL. Differential Revision: https://reviews.llvm.org/D155349 | 2 年前 | |
[libc++] Fix template parameter naming and enforce it through readability-identifier-naming Reviewed By: #libc, Mordante Spies: Mordante, aheejin, libcxx-commits Differential Revision: https://reviews.llvm.org/D156059 | 2 年前 | |
[libc++] Only include_next C library headers when they exist Some platforms don't provide all C library headers. In practice, libc++ only requires a few C library headers to exist, and only a few functions on those headers. Missing functions that libc++ doesn't need for its own implementation are handled properly by the using_if_exists attribute, however a missing header is currently a hard error when we try to do #include_next. This patch should make libc++ more flexible on platforms that do not provide C headers that libc++ doesn't actually require for its own implementation. The only downside is that it may move some errors from the #include_next point to later in the compilation if we actually try to use something that isn't provided, which could be somewhat confusing. However, these errors should be caught by folks trying to port libc++ over to a new platform (when running the libc++ test suite), not by end users. NOTE: This is a reapplicaton of 226409, which was reverted in 674729813 because it broke the build. The issue has now been fixed with https://reviews.llvm.org/D138062. Differential Revision: https://reviews.llvm.org/D136683 | 3 年前 | |
[libc++][hardening] Categorize most assertions inside the container classes. This introduces: - _LIBCPP_ASSERT_VALID_INPUT_RANGE; - _LIBCPP_ASSERT_VALID_CONTAINER_ACCESS; - _LIBCPP_ASSERT_VALID_ITERATOR_ACCESS; - _LIBCPP_ASSERT_VALID_ALLOCATOR; - _LIBCPP_ASSERT_INTERNAL. Differential Revision: https://reviews.llvm.org/D155349 | 2 年前 | |
[libc++] Remove Solaris related code This was contributed ~10 years ago, but we don't officially support it and I am not aware of any bot testing it, so this has likely rotten to the point where it is unusable. Differential Revision: https://reviews.llvm.org/D138680 | 3 年前 | |
[libc++][mdspan] Implement std::mdspan class This implements P0009 std::mdspan ((https://wg21.link/p0009)), a multidimensional span with customization points for layouts and data access. Co-authored-by: Damien L-G <dalg24@gmail.com> Differential Revision: https://reviews.llvm.org/154367 | 2 年前 | |
[libc++][spaceship] P1614R2: Removed global operator!= from allocator Implements parts of P1614R2: - Removed global operator!= from allocator Reviewed By: #libc, Mordante Differential Revision: https://reviews.llvm.org/D152612 | 3 年前 | |
[libc++][spaceship] P1614R2: Removed ops from memory_resource, polymorphic_allocator Implements parts of P1614R2 - Removed ops from memory_resource - Removed ops from polymorphic_allocator Reviewed By: #libc, Mordante Differential Revision: https://reviews.llvm.org/D152629 | 3 年前 | |
[libc++][Modules] Remove unnecessary requires from the module map Top level modules don't need requires because they're only built when their headers are included. Reviewed By: ldionne, Mordante, #libc Differential Revision: https://reviews.llvm.org/D157363 | 2 年前 | |
[libc++] Move __thread_id out of <__threading_support> This makes <__threading_support> closer to handling only the bridge between the system's implementation of threading and the rest of libc++. Differential Revision: https://reviews.llvm.org/D154464 | 2 年前 | |
Revert "[libc++] Remove the type_traits includes from limits and new" type_traits doesn't need to include __type_traits/noexcept_move_assign_container.h, so there is no include cycle from <limits> or <new>. Restore their includes of type_traits to preserve compatibility. This reverts commit 2af6d79c7e38675a184280a2d6a92550702581f7. Reviewed By: ldionne, #libc Differential Revision: https://reviews.llvm.org/D154747 | 2 年前 | |
[libc++][NFC] Replace _LIBCPP_STD_VER > x with _LIBCPP_STD_VER >= x This change is almost fully mechanical. The only interesting change is in generate_feature_test_macro_components.py to generate _LIBCPP_STD_VER >= instead. To avoid churn in the git-blame this commit should be added to the .git-blame-ignore-revs once committed. Reviewed By: ldionne, var-const, #libc Spies: jloser, libcxx-commits, arichardson, arphaman, wenlei Differential Revision: https://reviews.llvm.org/D143962 | 3 年前 | |
[libc++][PSTL] Implement std::reduce and std::transform_reduce Reviewed By: ldionne, #libc Spies: libcxx-commits, miyuki Differential Revision: https://reviews.llvm.org/D150736 | 3 年前 | |
[libc++] Fix template parameter naming and enforce it through readability-identifier-naming Reviewed By: #libc, Mordante Spies: Mordante, aheejin, libcxx-commits Differential Revision: https://reviews.llvm.org/D156059 | 2 年前 | |
Revert "[libc++] Apply _LIBCPP_EXCLUDE_FROM_EXPLICIT_INSTANTIATION only in classes that we have instantiated externally" This reverts commit b3c9150062dc4264afb4a3d2790f071c1ebe0743. There were unexpected breakages downstream. @EricWF is investigating. | 3 年前 | |
[libc++][print] Adds stdout functions. Implements parts of - P2093R14 Formatted output - P2539R4 Should the output of std::print to a terminal be synchronized with the underlying stream? Depends on D150044 Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D155262 | 2 年前 | |
[libc++] Fix template parameter naming and enforce it through readability-identifier-naming Reviewed By: #libc, Mordante Spies: Mordante, aheejin, libcxx-commits Differential Revision: https://reviews.llvm.org/D156059 | 2 年前 | |
[libc++] Remove <cstdlib> includes We changed the abort calls when trying to throw exceptions in -fno-exceptions mode to __verbose_abort calls, which removes the dependency in most files. Reviewed By: ldionne, #libc Spies: dim, emaste, mikhail.ramalho, smeenai, libcxx-commits Differential Revision: https://reviews.llvm.org/D146076 | 3 年前 | |
[libc++][ranges] Implement ranges::to. Differential Revision: https://reviews.llvm.org/D142335 | 2 年前 | |
[libc++] "Implements" new SI prefixis. Like yocto, zepto, zetta, and yotta. The new prefixes quecto, ronto, ronna, and quetta can't be implemented in a intmax_t. So their implementation does nothing. Implements - P2734R0 Adding the new SI prefixes Depends on D153192 Reviewed By: #libc, philnik Differential Revision: https://reviews.llvm.org/D153200 | 3 年前 | |
[libc++] Add missing includes Those were found while trying to enable configurations like no-threads and no-localization with Clang modules enabled. Differential Revision: https://reviews.llvm.org/D153977 | 2 年前 | |
Fixing conflicting macro definitions between curses.h and the standard library. POSIX allows certain macros to exist with generic names (i.e. refresh(), move(), and erase()) to exist in curses.h which conflict with functions found in std::filesystem, among others. This patch undefs the macros in question and adds them to LIBCPP_PUSH_MACROS and LIBCPP_POP_MACROS. Reviewed By: #libc, philnik, ldionne Differential Revision: https://reviews.llvm.org/D147356 | 2 年前 | |
[libc++] Fix template parameter naming and enforce it through readability-identifier-naming Reviewed By: #libc, Mordante Spies: Mordante, aheejin, libcxx-commits Differential Revision: https://reviews.llvm.org/D156059 | 2 年前 | |
[libc++][ranges] Implement the changes to node-based containers 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/D149830 | 2 年前 | |
[libc++] Only include_next C library headers when they exist Some platforms don't provide all C library headers. In practice, libc++ only requires a few C library headers to exist, and only a few functions on those headers. Missing functions that libc++ doesn't need for its own implementation are handled properly by the using_if_exists attribute, however a missing header is currently a hard error when we try to do #include_next. This patch should make libc++ more flexible on platforms that do not provide C headers that libc++ doesn't actually require for its own implementation. The only downside is that it may move some errors from the #include_next point to later in the compilation if we actually try to use something that isn't provided, which could be somewhat confusing. However, these errors should be caught by folks trying to port libc++ over to a new platform (when running the libc++ test suite), not by end users. NOTE: This is a reapplicaton of 226409, which was reverted in 674729813 because it broke the build. The issue has now been fixed with https://reviews.llvm.org/D138062. Differential Revision: https://reviews.llvm.org/D136683 | 3 年前 | |
[libc++] Fix template parameter naming and enforce it through readability-identifier-naming Reviewed By: #libc, Mordante Spies: Mordante, aheejin, libcxx-commits Differential Revision: https://reviews.llvm.org/D156059 | 2 年前 | |
[libc++] Don't try to provide source_location on AppleClang 1403 AppleClang 1403 has some bugs that prevent std::source_location from working properly on it. Consequently, we XFAILed the unit test for source_location with that compiler. However, we should also avoid advertising that the feature is supported on that compiler, otherwise our feature-test macros lie. This was noticed to break Boost.Asio when building with a recent libc++ and AppleClang 14.0.3. rdar://106863087 Differential Revision: https://reviews.llvm.org/D146837 | 3 年前 | |
[libc++][hardening] Categorize most assertions inside the container classes. This introduces: - _LIBCPP_ASSERT_VALID_INPUT_RANGE; - _LIBCPP_ASSERT_VALID_CONTAINER_ACCESS; - _LIBCPP_ASSERT_VALID_ITERATOR_ACCESS; - _LIBCPP_ASSERT_VALID_ALLOCATOR; - _LIBCPP_ASSERT_INTERNAL. Differential Revision: https://reviews.llvm.org/D155349 | 2 年前 | |
[libc++] Work around dynamic linking of stringstream::str() on Windows Also istringstream::str() and ostringstrem::str(). https://github.com/llvm/llvm-project/issues/40363 causes str() to be dllimport'ed despite _LIBCPP_HIDE_FROM_ABI. This is a temporary solution until #40363 is fixed. Reviewed By: #libc, thakis, philnik Differential Revision: https://reviews.llvm.org/D157602 (cherry picked from commit 090996f4a1186b1522e1225b6779d74ce9da250c) | 2 年前 | |
[libc++] Fix template parameter naming and enforce it through readability-identifier-naming Reviewed By: #libc, Mordante Spies: Mordante, aheejin, libcxx-commits Differential Revision: https://reviews.llvm.org/D156059 | 2 年前 | |
[libc++][NFC] Replace _LIBCPP_STD_VER > x with _LIBCPP_STD_VER >= x This change is almost fully mechanical. The only interesting change is in generate_feature_test_macro_components.py to generate _LIBCPP_STD_VER >= instead. To avoid churn in the git-blame this commit should be added to the .git-blame-ignore-revs once committed. Reviewed By: ldionne, var-const, #libc Spies: jloser, libcxx-commits, arichardson, arphaman, wenlei Differential Revision: https://reviews.llvm.org/D143962 | 3 年前 | |
[libc++][NFC] Consistently use newline between license and include guard | 3 年前 | |
Revert "[libc++] Remove workarounds for systems that used to require __need_XXX macros" This reverts commit 119cef40d18c48240854edc553dca61c4e9fdf27. The change broke multiple builders. | 3 年前 | |
[libc++] Merge _LIBCPP_FUNC_VIS, _LIBCPP_TYPE_VIS and _LIBCPP_EXCEPTION_ABI into _LIBCPP_EXPORTED_FROM_ABI These macros are always defined identically, so we can simplify the code a bit by merging them. Reviewed By: ldionne, #libc Spies: libcxx-commits, krytarowski, smeenai Differential Revision: https://reviews.llvm.org/D152652 | 3 年前 | |
[libc++] Only include_next C library headers when they exist Some platforms don't provide all C library headers. In practice, libc++ only requires a few C library headers to exist, and only a few functions on those headers. Missing functions that libc++ doesn't need for its own implementation are handled properly by the using_if_exists attribute, however a missing header is currently a hard error when we try to do #include_next. This patch should make libc++ more flexible on platforms that do not provide C headers that libc++ doesn't actually require for its own implementation. The only downside is that it may move some errors from the #include_next point to later in the compilation if we actually try to use something that isn't provided, which could be somewhat confusing. However, these errors should be caught by folks trying to port libc++ over to a new platform (when running the libc++ test suite), not by end users. NOTE: This is a reapplicaton of 226409, which was reverted in 674729813 because it broke the build. The issue has now been fixed with https://reviews.llvm.org/D138062. Differential Revision: https://reviews.llvm.org/D136683 | 3 年前 | |
Revert "[libc++] Remove workarounds for systems that used to require __need_XXX macros" This reverts commit 119cef40d18c48240854edc553dca61c4e9fdf27. The change broke multiple builders. | 3 年前 | |
[libc++] Remove Solaris related code This was contributed ~10 years ago, but we don't officially support it and I am not aware of any bot testing it, so this has likely rotten to the point where it is unusable. Differential Revision: https://reviews.llvm.org/D138680 | 3 年前 | |
[libc++] Implement stop_token Implement stop_token http://eel.is/c++draft/thread.stoptoken | 3 年前 | |
Revert "[libc++] Apply _LIBCPP_EXCLUDE_FROM_EXPLICIT_INSTANTIATION only in classes that we have instantiated externally" This reverts commit b3c9150062dc4264afb4a3d2790f071c1ebe0743. There were unexpected breakages downstream. @EricWF is investigating. | 3 年前 | |
[libc++][hardening] Categorize most assertions inside the container classes. This introduces: - _LIBCPP_ASSERT_VALID_INPUT_RANGE; - _LIBCPP_ASSERT_VALID_CONTAINER_ACCESS; - _LIBCPP_ASSERT_VALID_ITERATOR_ACCESS; - _LIBCPP_ASSERT_VALID_ALLOCATOR; - _LIBCPP_ASSERT_INTERNAL. Differential Revision: https://reviews.llvm.org/D155349 | 2 年前 | |
[libc++] Remove Solaris related code This was contributed ~10 years ago, but we don't officially support it and I am not aware of any bot testing it, so this has likely rotten to the point where it is unusable. Differential Revision: https://reviews.llvm.org/D138680 | 3 年前 | |
[libc++][hardening] Categorize most assertions inside the container classes. This introduces: - _LIBCPP_ASSERT_VALID_INPUT_RANGE; - _LIBCPP_ASSERT_VALID_CONTAINER_ACCESS; - _LIBCPP_ASSERT_VALID_ITERATOR_ACCESS; - _LIBCPP_ASSERT_VALID_ALLOCATOR; - _LIBCPP_ASSERT_INTERNAL. Differential Revision: https://reviews.llvm.org/D155349 | 2 年前 | |
[libc++] Merge _LIBCPP_FUNC_VIS, _LIBCPP_TYPE_VIS and _LIBCPP_EXCEPTION_ABI into _LIBCPP_EXPORTED_FROM_ABI These macros are always defined identically, so we can simplify the code a bit by merging them. Reviewed By: ldionne, #libc Spies: libcxx-commits, krytarowski, smeenai Differential Revision: https://reviews.llvm.org/D152652 | 3 年前 | |
[libc++] Move __errc to __system_error/errc.h This file was added before we started granularizing the headers, but is essentially just a granularized header. This moves the header to the correct place. Reviewed By: #libc, EricWF Spies: libcxx-commits, arichardson, mikhail.ramalho Differential Revision: https://reviews.llvm.org/D146395 | 3 年前 | |
[libc++] Only include_next C library headers when they exist Some platforms don't provide all C library headers. In practice, libc++ only requires a few C library headers to exist, and only a few functions on those headers. Missing functions that libc++ doesn't need for its own implementation are handled properly by the using_if_exists attribute, however a missing header is currently a hard error when we try to do #include_next. This patch should make libc++ more flexible on platforms that do not provide C headers that libc++ doesn't actually require for its own implementation. The only downside is that it may move some errors from the #include_next point to later in the compilation if we actually try to use something that isn't provided, which could be somewhat confusing. However, these errors should be caught by folks trying to port libc++ over to a new platform (when running the libc++ test suite), not by end users. NOTE: This is a reapplicaton of 226409, which was reverted in 674729813 because it broke the build. The issue has now been fixed with https://reviews.llvm.org/D138062. Differential Revision: https://reviews.llvm.org/D136683 | 3 年前 | |
[libc++][NFC] Granularise <thread> header - This was to make implementing jthread easier and requested in https://reviews.llvm.org/D151559 Differential Revision: https://reviews.llvm.org/D151792 | 3 年前 | |
[libc++] Fix template parameter naming and enforce it through readability-identifier-naming Reviewed By: #libc, Mordante Spies: Mordante, aheejin, libcxx-commits Differential Revision: https://reviews.llvm.org/D156059 | 2 年前 | |
[libc++] Untangles invoke. The type traits parts are moved to a type_traits detail header. This was discovered while working on modules. Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D150538 | 3 年前 | |
[libc++][NFC] Replace _LIBCPP_STD_VER > x with _LIBCPP_STD_VER >= x This change is almost fully mechanical. The only interesting change is in generate_feature_test_macro_components.py to generate _LIBCPP_STD_VER >= instead. To avoid churn in the git-blame this commit should be added to the .git-blame-ignore-revs once committed. Reviewed By: ldionne, var-const, #libc Spies: jloser, libcxx-commits, arichardson, arphaman, wenlei Differential Revision: https://reviews.llvm.org/D143962 | 3 年前 | |
[libc++] Merge _LIBCPP_FUNC_VIS, _LIBCPP_TYPE_VIS and _LIBCPP_EXCEPTION_ABI into _LIBCPP_EXPORTED_FROM_ABI These macros are always defined identically, so we can simplify the code a bit by merging them. Reviewed By: ldionne, #libc Spies: libcxx-commits, krytarowski, smeenai Differential Revision: https://reviews.llvm.org/D152652 | 3 年前 | |
[libc++] cuchar redeclares ::mbstate_t when it's in its own clang module When cuchar is compiled independently on platforms that don't have <uchar.h>, it doesn't get a declaration of mbstate_t, and so makes an empty declaration for ::mbstate_t. That conflicts with the declarations in __mbstate_t.h and cwchar since both of those headers do get mbstate_t before making ::mbstate_t. Change __mbstate_t.h to just get the underlying declaration for mbstate_t and not make a declaration for ::mbstate_t. Include __mbstate_t.h in uchar.h and wchar.h when their next headers aren't available so that at least mbstate_t gets defined. Add __std_mbstate_t.h to declare ::mbstate_t for headers that need that when cuchar or cwchar aren't available (because either _LIBCPP_HAS_NO_WIDE_CHARACTERS or _LIBCPP_CXX03_LANG). Reviewed By: ldionne, Mordante, #libc, philnik Differential Revision: https://reviews.llvm.org/D148542 | 3 年前 | |
[libc++][hardening] Categorize most assertions inside the container classes. This introduces: - _LIBCPP_ASSERT_VALID_INPUT_RANGE; - _LIBCPP_ASSERT_VALID_CONTAINER_ACCESS; - _LIBCPP_ASSERT_VALID_ITERATOR_ACCESS; - _LIBCPP_ASSERT_VALID_ALLOCATOR; - _LIBCPP_ASSERT_INTERNAL. Differential Revision: https://reviews.llvm.org/D155349 | 2 年前 | |
[libc++][hardening] Categorize most assertions inside the container classes. This introduces: - _LIBCPP_ASSERT_VALID_INPUT_RANGE; - _LIBCPP_ASSERT_VALID_CONTAINER_ACCESS; - _LIBCPP_ASSERT_VALID_ITERATOR_ACCESS; - _LIBCPP_ASSERT_VALID_ALLOCATOR; - _LIBCPP_ASSERT_INTERNAL. Differential Revision: https://reviews.llvm.org/D155349 | 2 年前 | |
[libc++] Updates C++2b to C++23. During the ISO C++ Committee meeting plenary session the C++23 Standard has been voted as technical complete. This updates the reference to c++2b to c++23 and updates the __cplusplus macro. Note since we use clang-tidy 16 a small work-around is needed. Clang knows -std=c++23 but clang-tidy not so for now force the lit compiler flag to use -std=c++2b instead of -std=c++23. Reviewed By: #libc, philnik, jloser, ldionne Differential Revision: https://reviews.llvm.org/D150795 | 3 年前 | |
[libc++] Merge _LIBCPP_FUNC_VIS, _LIBCPP_TYPE_VIS and _LIBCPP_EXCEPTION_ABI into _LIBCPP_EXPORTED_FROM_ABI These macros are always defined identically, so we can simplify the code a bit by merging them. Reviewed By: ldionne, #libc Spies: libcxx-commits, krytarowski, smeenai Differential Revision: https://reviews.llvm.org/D152652 | 3 年前 | |
[libc++] Fix template parameter naming and enforce it through readability-identifier-naming Reviewed By: #libc, Mordante Spies: Mordante, aheejin, libcxx-commits Differential Revision: https://reviews.llvm.org/D156059 | 2 年前 | |
[libc++] Fix template parameter naming and enforce it through readability-identifier-naming Reviewed By: #libc, Mordante Spies: Mordante, aheejin, libcxx-commits Differential Revision: https://reviews.llvm.org/D156059 | 2 年前 | |
[libc++][ranges] Implement ranges::to. Differential Revision: https://reviews.llvm.org/D142335 | 2 年前 | |
[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 年前 | |
[libc++] Normalize all our '#pragma GCC system_header', and regression-test. Now we'll notice if a header forgets to include this magic phrase. Differential Revision: https://reviews.llvm.org/D118800 | 4 年前 |