Most notably, this removes the notion of a distinct `value_type` and
`__container_value_type` from `__tree`, since these are now always the
same type. There are a few places we need to keep `__value_type` around,
since they are ABI visibile. In these cases `_Tp` is used directly. The
second simplification here is that we use `const value_type&` instead of
`const key_type&` in a few places and make use of the fact that the
comparator is capable of comparing any combination of `key_type` and
`value_type`.
This is a follow-up to #134819.
This does a few small things:
- inline `__libcpp_compute_min`, since we can don't have to put the
arithmetic behind a constraint. Simple arithmetic also tends to be
faster to compile than instantiating a type.
- Remove an unused include (and add missing includes elsewhere)
- Remove `__min` and `__max` from the `bool` specialization
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
Since we've removed allocator support, we can remove a few support
structures. This only affects the policy implementation, so this
shouldn't even be ABI sensitive.
`template <class = int>` is also added to our implementations to avoid
an ambiguity between the libc's version and our version when both are
visible.
This avoids including `<stdlib.h>` in `<math.h>`.
Previously, the segmented iterator optimization was limited to `std::{for_each, for_each_n}`. This patch
extends the optimization to `std::ranges::for_each` and `std::ranges::for_each_n`, ensuring consistent
optimizations across these algorithms. This patch first generalizes the `std` algorithms by introducing
a `Projection` parameter, which is set to `__identity` for the `std` algorithms. Then we let the `ranges`
algorithms to directly call their `std` counterparts with a general `__proj` argument. Benchmarks
demonstrate performance improvements of up to 21.4x for ``std::deque::iterator`` and 22.3x for
``join_view`` of ``vector<vector<char>>``.
Addresses a subtask of #102817.
`__has_iterator_typedefs` is only used in the up-to-C++17 implementation
of `type_traits`. To make that clearer the struct is moved into that
code block.
This newline was originally added in https://reviews.llvm.org/D142184
but I think updating `__libcpp_verbose_abort` to add newline instead is
more consistent, and works for other callers of `_LIBCPP_VERBOSE_ABORT`.
The `_LIBCPP_ASSERTION_HANDLER` calls through to either
`_LIBCPP_VERBOSE_ABORT` macro or the `__builtin_verbose_trap`. From what
I can tell neither of these function expect a trailing newline (at least
none of the usage of `_LIBCPP_VERBOSE_ABORT` or `__builtin_verbose_trap`
that I can find include a trailing newline except `_LIBCPP_ASSERTION_HANDLER`).
I noticed this discrepancy when working on
https://github.com/emscripten-core/emscripten/pull/24543
The implementation of std::basic_streambuf used private member variables
to manipulate the get and the put areas. Using public API functions is
equivalent but leads to code that is easier to understand, since the
public API functions are known more widely than our internal member
variables. Using the public API functions removes the need to map the
internal member variables back to get/put area manipulation functions in
one's head.
Finally, it also makes it easier to find subtle issues by instrumenting
accessor functions, which is impossible if the class uses the member
variables directly.
Updates the implementation `std::reference_wrapper` -
[P2944R3](https://wg21.link/P2944R3) as discussed in
https://github.com/llvm/llvm-project/pull/117664#discussion_r1857826166
This PR also refactors the tests in preparation to implements the
constrained comparisons for `optional`, `variant` etc.
- Moves the test helpers (concepts and types) for testing constrained
comparisons to `test_comparisons.h`.
- Updates the `std::reference_wrapper` implementation to use the concept
`__core_convertible_to<bool>` as per comments in #135759.
Closes#138233
# References:
- [refwrap.comparisons](https://wg21.link/refwrap.comparisons)
---------
Co-authored-by: Hristo Hristov <zingam@outlook.com>
Co-authored-by: Nikolas Klauser <nikolasklauser@berlin.de>
Unconditional evaluation of `char_traits<_CharT>::length(__str)` is problematic, because it causes
UB when `__str` points to a non-null-terminated array. We should only call `length` (currently, in
`basic_string_view`'s constructor) when `__n == npos` per [bitset.cons]/8.
Drive-by change: Reduction of conditional compilation, given that
- both `basic_string_view<_CharT>::size_type` and `basic_string<_CharT>::size_type` must be
`size_t`, and thus
- both `basic_string_view<_CharT>::npos` and `basic_string<_CharT>::npos` must be `size_t(-1)`.
For the type sameness in the standard wording, see:
- [string.view.template.general]
- [basic.string.general]
- [allocator.traits.types]/6
- [default.allocator.general]/1
Fixes#143684
The allocator support was removed in P0302R1, since it was impossible to
implement. We're currently providing the API for this, but ignore the
allocator in all cases but one (which is almost certainly an oversight).
That case is the `function(allocator_arg_t, const Alloc&, Func)`
constuctor. IMO we should remove the API entirely at a later date, but
this only removes most of the code for now, leaving only the public
functions. This not only simplifies the code quite a bit, but also
results in the constructor being instantiated ~8x faster.
Fixes#133901
This patch does a few things:
- `__libcpp_is_signed_integer` and `__libcpp_is_unsigned_integer` are
refactored to be variable templates instead of class templates.
- the two traits are merged into a single header
`<__type_traits/integer_traits.h>`.
- `__libcpp_signed_integer`, `__libcpp_unsigned_integer` and
`__libcpp_integer` are moved into the same header.
- The above mentioned concepts are renamed to `__signed_integer`,
`__unsigned_integer` and `__signed_or_unsigned_integer` respectively.
Currently these two functions are constrained on `is_unsigned`, which is
more permissive than what is required by the standard for their public
counterparts. This fixes the constraints to match the public functions
by using `__libcpp_is_unsigned_integer` instead.
This was part of https://wg21.link/p0355r7, but apparently never
implemented.
---------
Co-authored-by: MarcoFalke <*~=`'#}+{/-|&$^_@721217.xyz>
Co-authored-by: Hristo Hristov <zingam@outlook.com>
When localization is disabled, we used to skip testing a lot of headers.
However, these headers are now "no-ops" when localization is disabled,
so they can actually be included. As such, we should test their
inclusion in our usual header inclusion tests.
Instead of providing full specializations of `hash` for every arithmetic
type, this moves the implementation to a base class, which is
specialized via `enable_if`s instead.
The libc++ build includes a step where headers are generated. This is
required in order to preprocess some files such as the assertion handler
and the __config_site header. As a result, the library is built against
headers located inside the build directory, and the path to those
headers is what's included in the debug information of the library.
However, these headers in the build directory are usually not
persistent, which means that the debug information might end up
referring to headers that don't exist anymore. To solve this problem,
this patch uses the -fdebug-prefix-map flag supported by Clang and GCC
to remap the generated headers to the original headers in the source
directory. This provides the illusion that the library was truly built
against the in-source version of the headers.
This patch includes __fwd/span.h in <mdspan> so that we get the
declaration of dynamic_extent inside <mdspan>. We also clean up quite a
few tests that were manually included <span> for dynamic_extent.
This is based on feedback from #142693.
Reviewers: philnik777, ldionne
Reviewed By: philnik777
Pull Request: https://github.com/llvm/llvm-project/pull/142925
This is brought up in the LWG reflector. We currently call `reserve` if
the underlying container has one. But the spec does not specify what
`reserve` should do for Sequence Container. So in theory if the
underlying container is user defined type and it can have a function
called `reserve` which does something completely different.
The fix is to just call `reserve` for STL containers if it has one
See discussion in https://cplusplus.github.io/LWG/issue4239
std::flat_map<std::string, int, std::less<>> m;
m.try_emplace("abc", 5); // hard error
The reason is that we specify in 23.6.8.7 [flat.map.modifiers]/p21
the effect to be as if `ranges::upper_bound` is called.
`ranges::upper_bound` requires indirect_strict_weak_order, which
requires the comparator to be invocable for all combinations. In this
case, it requires
const char (&)[4] < const char (&)[4]
to be well-formed, which is no longer the case in C++26 after
https://wg21.link/P2865R6.
This patch uses `std::upper_bound` instead.
`_ITER_TRAITS` and `_ITER_CONCEPT` are really implenentation details of
`<__iterator/concetps.h>`, so it makes more sense to put them there than
into `<__iterator/iterator_traits.h>`.
Currently, when the string shrink into the SSO buffer, the `__rep_.__s`
member isn't activated before the `traits_type::copy` call
yet, so internal `__builtin_memmove` call writing to the buffer causes
constant evaluation failure. The existing test coverage seems a bit
defective and doesn't cover this case - `shrink_to_fit` is called on the
copy of string after erasure, not the original string object.
This PR reorders the `__set_short_size` call, which starts the lifetime
of the SSO buffer, before the copy operation. Test coverage is achieved
by calling `shrink_to_fit` on the original erased string.
The current implementation of `forward_list::resize` does not meet the
strong exception safety guarantee required by [forward.list.modifiers]:
If an exception is thrown by any of these member functions there is no
effect on the container.
This patch refactors `resize()` to provide strong exception safety and
introduces additional tests to validate the strong exception guarantees
for other `forward_list` modifiers.
Fixes#118366.
`common_reference` isn't an exception for [meta.rqmts]/4, so it's better
to disallow users to specialize it.
`indirectly_readable.compile.pass.cpp` was a bit problematic. It
attempted to opt-out common reference type in some wrong ways. Also, the
standard effectively forbids opting-out common reference type for `T&`
and `T&&`. This patch removes and adjusts some problematic cases.
---------
Co-authored-by: Nikolas Klauser <nikolasklauser@berlin.de>
#109028 caused `sizeof` to be sometimes applied to function reference
types, which makes a program ill-formed. This PR handles reference types
by specializations to prevent such bogus `sizeof` expression to be
instantiated.
Fixes#142118.
Currently, libc++'s `<tuple>` is using the deprecated
`__reference_binds_to_temporary` intrinsic. This PR starts to use
`__reference_constructs_from_temporary` if possible.
It seems that `__reference_constructs_from_temporary` should be used via
an internal type traits provided in
`<__type_traits/reference_constructs_from_temporary.h>`. But given the
old intrinsic was directly used, this PR doesn't switch to the current
convention yet.
P2255R2 is related. Although the paper indicated that constructors of
`tuple` should be deleted in such a case.
---------
Co-authored-by: Nikolas Klauser <nikolasklauser@berlin.de>
The ABI bump to adopt the conforming ABI v1 std::pair implementation did
not end up happening for FreeBSD 14, and instead this diff was reverted
downstream in FreeBSD[1]. Align the upstream ABI config with FreeBSD's
actual ABI.
[1] ce4f1f49e036 ("Revert commit 6255157d24e2 from llvm-project (by
Dimitry Andric):")
This reverts commit 6255157d24e27c604bda8fe8ce26e896f54785c0.
Fixes#135351
This PR update CATD guides to associative containers (`std::map`,
`std::multimap`, `std::unordered_map`, `std::unordered_multimap`,
`std::flat_map`, `std::flat_multimap`).
- Updated template alias for deduction guides for the relevant
associative containers.
- Added a new test to verify the deduction guides with `std::map`,
`std::multimap`, `std::unordered_map`, `std::unordered_multimap`,
`std::flat_map`, `std::flat_multimap`.
This patch refactors the `all()` and `any()` methods in `bitset` to
eliminate redundant code while preserving the performance. Code
generation remains unchanged, as verified on Compiler
Explorer: https://godbolt.org/z/xx8hb4sPM.
This PR simplifies `__bitset::__init` into a more compact and readable
form, which avoids redundant computations of a `size_t` value and
eliminates the overhead of a local array.
This reverts commit c861fe8a71e64f3d2108c58147e7375cd9314521.
Unfortunately, this use of hidden visibility attributes causes
user-defined specializations of standard-library types to also be marked
hidden by default, which is incorrect. See discussion thread on #131156.
...and also reverts the follow-up commits:
Revert "[libc++] Add explicit ABI annotations to functions from the block runtime declared in <__functional/function.h> (#140592)"
This reverts commit 3e4c9dc299c35155934688184319d391b298fff7.
Revert "[libc++] Make ABI annotations explicit for windows-specific code (#140507)"
This reverts commit f73287e623a6c2e4a3485832bc3e10860cd26eb5.
Revert "[libc++][NFC] Replace a few "namespace std" with the correct macro (#140510)"
This reverts commit 1d411f27c769a32cb22ce50b9dc4421e34fd40dd.
We've added a new macro for the unversioned `namespace std` cases in
#133009, but it seems we've missed a few places. This fixes the places I
just found.
This patch optimizes `bitset::to_string` by replacing the existing bit-by-bit processing with a more efficient
bit traversal strategy. Instead of checking each bit sequentially, we leverage `std::__countr_zero` to efficiently
locate the next set bit, skipping over consecutive zero bits. This greatly accelerates the conversion process,
especially for sparse `bitset`s where zero bits dominate. To ensure similar improvements for dense `bitset`s, we
exploit symmetry by inverting the bit pattern, allowing us to apply the same optimized traversal technique. Even
for uniformly distributed `bitset`s, the proposed approach offers measurable performance gains over the existing
implementation.
Benchmarks demonstrate substantial improvements, achieving up to 13.5x speedup for sparse `bitset`s with
`Pr(true bit) = 0.1`, 16.1x for dense `bitset`s with `Pr(true bit) = 0.9`, and 8.3x for uniformly distributed
`bitset`s with `Pr(true bit) = 0.5)`.
