Drive-by fix to make sure the __retarget_buffer works correctly whan
using a hint of 1. This was discovered in one of the new tests.
Drive-by fixes __retarget_buffer when initialized with size 1.
Implements parts of
- P2093R14 Formatted output
- P2539R4 Should the output of std::print to a terminal be
synchronized with the underlying stream?
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D150044
This way, we don't need to remove the contents of the ReleaseNotes file
after the branch. This should make it much easier and natural to cherry-pick
changes onto the release branch. Typically, we need two patches for those.
First, we need the code changes against `main`, and then we need a patch
that updates the release notes on the just-created branch.
By versioning the release notes, it becomes easy to author a change
against `main` that targets a just-branched LLVM release by simply
adding it to the release notes for the right version. This has been
a pain point in previous releases.
Differential Revision: https://reviews.llvm.org/D155024
This is a preparation for the upcoming LLVM 17 release.
Reviewed By: ldionne, jloser, H-G-Hristov, #libc
Differential Revision: https://reviews.llvm.org/D154874
Our threading support layer is currently a huge mess. There are too many
configurations with too many confusing names, and none of them are tested
in the usual CI. Here's a list of names related to these configurations:
LIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY
_LIBCPP_BUILDING_THREAD_LIBRARY_EXTERNAL
LIBCXXABI_BUILD_EXTERNAL_THREAD_LIBRARY
_LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL
LIBCXX_HAS_EXTERNAL_THREAD_API
_LIBCPP_HAS_THREAD_API_EXTERNAL
This patch cleans this up by removing the ability to build libc++ with
an "external" threading library for testing purposes, removing 4 out of
6 "names" above. That setting was meant to be used by libc++ developers,
but we don't use it in-tree and it's not part of our CI.
I know the ability to use an external threading API is used by some folks
out-of-tree, and this patch doesn't change that. This only changes the
way they will have to test their external threading support. After this
patch, the intent would be for them to set `-DLIBCXX_HAS_EXTERNAL_THREAD_API=ON`
when building the library, and to provide their usual `<__external_threading>`
header when they are testing the library. This can be done easily now
that we support custom lit configuration files in test suites.
The motivation for this patch is that our threading support layer is
basically unmaintainable -- anything beyond adding a new "backend" in
the slot designed for it requires incredible attention. The complexity
added by this setting just doesn't pull its weigh considering the
available alternatives.
Concretely, this will also allow future patches to clean up
`<__threading_support>` significantly.
Differential Revision: https://reviews.llvm.org/D154466
`_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
This commit implements default_accessor in support of C++23 mdspan
(https://wg21.link/p0009). default_accessor is the trivial accessor
using plain pointers and reference to element types.
Co-authored-by: Damien L-G <dalg24@gmail.com>
Differential Revision: https://reviews.llvm.org/D153935
This patch only adds new configuration knobs -- the actual assertions
will be added in follow-up patches.
Differential Revision: https://reviews.llvm.org/D153902
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
Note libc++ implemented this in its initial version. It always used the type
from the C library and never validated whether it was an integer type.
Implements
- LWG3905 Type of std::fexcept_t
Reviewed By: #libc, philnik
Differential Revision: https://reviews.llvm.org/D153285
Note libc++ actually implemented this wording from the start (D49338).
The Clang version is the same as the version that implements
P0122R7 <span>
Implements
- LWG3903 span destructor is redundantly noexcept
Reviewed By: #libc, philnik
Differential Revision: https://reviews.llvm.org/D153284
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
The feature is applied as DR instead of a normal paper. MSVC STL and
libstdc++ will do the same.
Implements
- P2510R3 Formatting pointers
Depends on D153192
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D153195
We use 17.0 instead of Clang 17 in our status tables pretty consistently,
but not universally. This ensures that we do it universally, for all
versions.
Differential Revision: https://reviews.llvm.org/D154461
Work on the missing chrono parts has started, but their operators will
be added in different patches. So split the remaining chrono part to one
entry per line and mark them in progress.
This commit implements layout_left in support of C++23 mdspan
(https://wg21.link/p0009). layout_left is a layout mapping policy
whose index mapping corresponds to the memory layout of Fortran arrays.
Thus the left most index has stride-1 access, and the right most index
is associated with the largest stride.
Co-authored-by: Damien L-G <dalg24@gmail.com>
Differential Revision: https://reviews.llvm.org/D153783
This commit implements layout_right in support of C++23 mdspan
(https://wg21.link/p0009). layout_right is a layout mapping policy
whose index mapping corresponds to the memory layout of multidimensional
C-arrays, and is thus also referred to as the C-layout.
Co-authored-by: Damien L-G <dalg24@gmail.com>
Differential Revision: https://reviews.llvm.org/D151267
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
Implement P2494R2 `Relaxing range adaptors to allow for move only types`
https://open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2494r2.html#wording-ftm
According to the words in P2494R2, I haven't add new test for `drop_while_view`, `take_while_view` and `filter_view`, because these views has the requirement that the predicate is an `indirect_unary_predicate`, which requires that the predicate is `copy_constructible`, so they still can't accept move only types as predicate.
```
[P2483R0] also suggests future work to relax the requirements on the predicate types stored by standard views. This paper does not perform this relaxation, as the copy constructibility requirement is enshrined in the indirect callable concepts ([indirectcallable.indirectinvocable]). Thus, while this paper modifies the views that currently use copyable-box for user provided predicates, it only does so to apply the rename of the exposition-only type to movable-box; it does not change any of the constraints on those views. It does, however, relax the requirements on invocables accepted by the transform family of views, because those are not constrained using the indirect callable concepts.
```
Reviewed By: #libc, var-const
Differential Revision: https://reviews.llvm.org/D151629
type_traits is currently unable to include __type_traits/noexcept_move_assign_container.h, because it would cause several include cycles.
type_traits -> __type_traits/noexcept_move_assign_container.h -> __memory/allocator_traits.h -> __memory/construct_at.h -> new -> exception -> type_traits
type_traits -> __type_traits/noexcept_move_assign_container.h -> __memory/allocator_traits.h -> __memory/construct_at.h -> new -> type_traits
type_traits -> __type_traits/noexcept_move_assign_container.h -> __memory/allocator_traits.h -> limits -> type_traits
This is a problem for clang modules after the std mega module is broken up (D144322), because it becomes a module cycle which is a hard error.
Unconditionally remove the type_traits includes from limits and new in all versions, and also remove the exception include from new. (These are already removed in C++23.)
Reviewed By: ldionne, Mordante, #libc
Differential Revision: https://reviews.llvm.org/D153214
This change has a few additional effects:
- Abstract classes are now formattable.
- Volatile objects are no longer formattable.
Implements
- LWG3631 basic_format_arg(T&&) should use remove_cvref_t<T> throughout
- LWG3925 Concept formattable's definition is incorrect
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D152092
Changes to preconditions have no impact on the library.
Implements
- LWG3927 Unclear preconditions for operator[] for sequence containers
Reviewed By: #libc, philnik
Differential Revision: https://reviews.llvm.org/D153286
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
This FTM was introduced in
P0553R4 Bit operations
Which has been implemented since libc++ 9.
This was noticed while working on D153192.
Reviewed By: #libc, philnik
Differential Revision: https://reviews.llvm.org/D153225
This updates:
- The status tables
- Feature test macros
- New headers for modules
The latter avoids forgetting about modules when implementing the feature
in a new header.
Reviewed By: #libc, philnik
Differential Revision: https://reviews.llvm.org/D153192
The development of C++23 is complete, so these issues will be adopted in
C++26 (or later).
Reviewed By: #libc, philnik
Differential Revision: https://reviews.llvm.org/D153053
The patch is based on D144994.
D151030 added the module definitions for the module std.
This patch wires in the module and enables the basic testing.
Some notable features are missing:
- There is no test that libc++ can be fully imported as a module.
- This lacks the parts for the std.compat module.
- The module is not shipped with libc++.
Implements parts of
- P2465R3 Standard Library Modules std and std.compat
Reviewed By: ldionne, aaronmondal, #libc
Differential Revision: https://reviews.llvm.org/D151814
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
Header synospis sections of P1614R2 are implemented by other items usually. For completeness, let's mark some of them as "Complete".
Reviewed By: #libc, Mordante
Differential Revision: https://reviews.llvm.org/D152775
