We're currently unwrapping `less<T>` even if the `key_type` isn't `T`.
This causes the removal of an implicit conversion to `const T&` if the
types mismatch. Making `less<T>` transparent in that case changes
overload resolution and makes it fail potentially.
Fixes#179319
To reduce the noise in #134330 for `libcxx/include/__tree`, we migrate
from certain `static_cast` to `std::__static_fancy_pointer_cast` in this
separate patch.
This change is needed to properly work with fancy pointers like
`min_pointer` during constant evaluation for `std::map`
Co-authored-by: Joseph Huber <huberjn@outlook.com>
`-Wchanges-meaning` is a GCC warning that catches shadowing in more
contexts. While a bit annoying here, it's a helpful warning. As such, we
need to rename the `__split_buffer` alias template in `std::vector` so
that we don't trip it up.
`__add_alignment_assumption` unilaterally returned a `pointer`, even
when passed a `const_pointer`. This was surfaced by some (but not all)
CI jobs when rebasing `std::vector` to have a layout type.
3a653afd45709432181952c0ffdb53eceb0939ae removed the inclusion of
`<__utility/declval.h>` from `<__algorithm/unwrap_range.h>`. However,
`unwrap_range.h` still needs to use `std::declval`. So we should restore
the inclusion.
The building failure with Clang modules was already caught by CI.
We currently have a custom utility `__reverse_range`, which does
basically the same thing as `views::reverse` and the only place where we
use it is in `ranges::reverse_copy`. Instead of this special utility, we
can simply use `views::reverse`.
This has originally been introduced due to compile time concerns.
However, there doesn't seem to actually be a significant compile time
regression overall.
We can use a relatively simple `if constexpr` chain instead of SFINAE
and class template specialization, making the functions much simpler to
understand.
These templates are instantiated whenever `<__chrono/duration.h>` is
included, making these calculations quite costly. I also don't think
that folding the calculations decreases readability here (IMO it's
actually easier to read now), so I don't think there is a reason we
shouldn't do this.
`<__chrono/duration.h>` is currently (transitively) included in at least
(I stopped checking) `<algorithm>`, `<atomic>`, `<barrier>`, `<chrono>`,
`<condition_variable>`, `<future>`, `<iomanip>`, `<ios>`, `<iostream>`,
`<istream>`, `<latch>`, `<locale>`, `<mutex>`, `<ostream>`,
`<semaphore>`, `<shared_mutex>`, `<syncstream>` and `<thread>`
Create a new `__capacity_aware_iterator` iterator type which wraps an
existing iterator, takes its container as a template parameter, and
encodes the maximum amount of elements the container can hold. The main
objective is to prevent iterator mixups between different containers
(e.g. `vector`).
When a default template argument of a function template uses
`std::is_copy_constructible<T>::value` and `T` is convertible from and
to `any`, the changes in 21dc73f6a46cd786394f10f5aef46ec4a2d26175 would
introduce constraint meta-recursion when compiling with Clang.
This patch short-cuts constraints of the related constructor to avoid
computing `is_copy_constructible<T>` when `decay_t<T>` is `any`, which
gets rid of constraint meta-recursion in the overload resolution of copy
construction of `T`.
Fixes#176877.
In https://github.com/llvm/llvm-project/pull/176903, `#include
<__configuration/compiler.h>` is moved into the
`#ifdef _cplusplus` clause, so `_LIBCPP_COMPILER_CLANG_BASED` is no
longer set for C compiles. This causes a regression internally, where
when C compiles includes stdatomic.h, they no longer get the
corresponding C header.
C++ stdlib headers "shouldn't" be on the search patch for C compile, but
we do and so do lots of other people, so libc++ tends to support that.
This include_next for a C compile should be unconditional, not
conditional upon being Clang.
`__is_continuation` is only used in contexts where we already know that
the argument is a contiguous iterator. However, due to the context in
which it is used, we check it as soon as the header is included. The
`contiguous_iterator` check is quite expensive (~12ms on my system), so
avoiding it reduces compile times for quite a few headers, including
`<vector>`.
`std::launch::any` was a draft C++11 feature that was removed before the
final standard but it has remained in libc++ as an extension. This patch
marks it as deprecated and suggests using `std::launch::async |
std::launch::deferred` instead.
- Used `_LIBCPP_DEPRECATED_` to mark `std::launch::any` as deprecated
with an associated warning message recommending `std::launch::async |
std::launch::deferred` instead.
- Added a `.verify.cpp` test to validate the deprecation warning.
- Updated existing tests to avoid using the deprecated extension.
- Added note about deprecation in docs.
Fixes#173219
---------
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
As `__split_buffer` doesn't have any unit tests, and because #139632
disassociated adding `__split_buffer` support for both pointer-based and
size-based layouts from its `vector` counterpart, libc++ had no way to
expose `__split_buffer_size_layout` bugs until the size-based vector
patch integrated #139632. This commit fixes the two problems that were
identified while working on #155330.
`_LIBCPP_FREESTANDING` isn't used and it is unclear what libc++'s
strategy is going to be for implementing freestanding at the moment.
Therefore, remove the macro.
This avoids instantiating some code that we know is dead. This is also a
prerequisite for #134330, since we avoid trying to `const_cast` in the
common case now.
This PR implements a generic backend-agnostic parallel `std::is_sorted`
based on `std::transform_reduce`.
While this approach is suboptimal comparing a direct backend-specific
implementation, since it doesn't support early termination and requires
a reduction operation, it does show speedup when the dataset is large
enough and the comparator is not absolutely trivial.
Parent issue: #99938
Address sanitizer recently got a new macro __SANITIZER_DISABLE_CONTAINER_OVERFLOW__
which is intended to disable container overflow checks in libraries (either the
standard library or user libraries that might provide such checks). This patch makes
libc++ honor that macro and, in addition, cleans up how these checks are enabled for
string (which is special) by introducing a macro just for string.
rdar://166234942
This allows us to make use of any optimizations to `std::swap_ranges` in
`ranges::swap_ranges`.
This patch also moves some code specific to `ranges::swap_ranges` into
`ranges_swap_ranges.h`.
When doing amortized growth we currently have separate functions for
calculating the new capacity and allocating. However, we set the size to
the calculated capacity that way instead of the actually required size.
This makes the interface quite confusing, since the size has to be set
manually. Instead, this patch refactors the function to get the
amortized growth capacity to instead allocate and set the size
correctly.
We don't need to use `std::distance`, since we know for a fact that we
have random access iterators in that place. Instead, we can just
subtract the iterators, avoiding a bunch of template machinery and
imrpoving compile times a bit.
Instead of unwrapping the arguments to string's observer functions
everywhere, simply unwrap the specific argument and then forward all of
them to a single function which does the final unwrapping of `*this`.
This simplifies the code a bit.
This patch moves all macros which expand to attributes into a detail
header, including the relatively complex visibility and ABI-hiding
attributes. This also adds sections for attributes that are important to
not be ignored. At the bottom there is a catch-all section for
attributes which can safely be ignored and are only important for the
quality of implementation.
Review in #176857 asked to remove this block and make
_LIBCPP_AVAILABILITY_HAS_INIT_PRIMARY_EXCEPTION similar
to the other availability macros. This patch does this.
P2321R2 has been implemented in various PRs. Based on the discussion
in #105169, the last bit in iterator.concept.winc doesn't require
any changes, so we can actually mark this as done.
Fixes#105169
This doesn't improve compile times currently, but it does make it clear
that we don't need the definition of `shared_ptr` or `unique_ptr` for
`{in,}out_ptr`. It also reduces compile times quite a bit if we ever use
these utilities in another header.
The existence of <float.h> in libc++ leads to difficulties with modules,
especially when it comes to supporting the various __need macros
supported by the Clang builtin headers.
Fortunately, libc++'s <float.h> only defines FLT_EVAL_METHOD and
DECIMAL_DIG, which are already defined by the Clang builtin headers in
C++11 mode. Hence, removing the header entirely should have no impact,
apart from not defining FLT_EVAL_METHOD and DECIMAL_DIG in C++03 mode.
However, that is arguably something that libc++ shouldn't be doing: if
the underlying C library doesn't want to provide these definitions, then
libc++ shouldn't force it to.
#175913 removed that `__builtin_assume_dereferenceable(ptr, 0)` implies
`ptr != nullptr`, which should allow us to use the builtin with LLVM 23.
This reverts commit 776c09c212e945fdceeae240b42c38df3dd34727.
It's a bit awkward to pass the char* and the size to the function, which
then only decides whether it should be a no-op with it. Instead, only
call the function when the pointer is null and n is 0, which matches
more closely what the standard says with respect to calling pubsetbuf(0, 0).
`__builtin_assume_dereferenceable` currently implies that the pointer
given to it is non-null, even if the size is zero. This causes
miscompilations, since we consider [nullptr, nullptr) to be a valid
range.
Reverts llvm/llvm-project#167697
`__unwrap_iter` doesn't need to SFINAE away, so we can just check inside
the function body whether an iterator is copy constructible. This
reduces the overload set, improving compile times a bit.
