This also updates the moved code to the current style. (i.e. `_VSTD` -> `std`, `_LIBCPP_INLINE_VISIBILITY` -> `_LIBCPP_HIDE_FROM_ABI`, clang-format).
Reviewed By: Mordante, #libc, EricWF
Spies: arichardson, libcxx-commits, mikhail.ramalho
Differential Revision: https://reviews.llvm.org/D146228
As explained in the release note, libc++ used to provide various
global variables as an extension in C++03 mode. Unfortunately, that
made our definition non-conforming in all standard modes. This was
never a big problem until recently, since we are trying to support
C++20 Modules in libc++, and that requires cleaning up the definition
of these variables.
This change is the first in a series of changes to achieve our end goal.
This patch removes the ability for users to rely on the (incorrect)
definition of those global variables inside the shared library. The
plan is to then remove those definitions from the shared library
(which is an ABI break but I don't think it will have impact), and
finally to make our definition of those variables conforming in all
standard modes.
Differential Revision: https://reviews.llvm.org/D145422
The original `__dynamic_cast` implementation does not use the ABI-provided `src2dst_offset` parameter which helps improve performance on the hot paths. This patch improves the performance on the hot paths in `__dynamic_cast` by leveraging hints provided by the `src2dst_offset` parameter. This patch also includes a performance benchmark suite for the `__dynamic_cast` implementation.
Reviewed By: philnik, ldionne, #libc, #libc_abi, avogelsgesang
Spies: mikhail.ramalho, avogelsgesang, xingxue, libcxx-commits
Differential Revision: https://reviews.llvm.org/D138005
Implements parts of P1614R2: `operator<=>` for `map` and `multimap`
Reviewed By: #libc, philnik
Spies: philnik, libcxx-commits, yaxunl
Differential Revision: https://reviews.llvm.org/D145976
This patch bumps the minimum macOS version for building the dylib
or back-deploying a statically-linked libc++ from macOS 10.11 to
macOS 10.13. AFAICT, Chrome was the last one to require macOS 10.11,
but since then they have bumped their minimal supported version to
macOS 10.13.
Differential Revision: https://reviews.llvm.org/D145012
LWG3358 §[span.cons] is mistaken that to_address can throw
Since last - first has to throw tests are added to make sure this always
happens.
Depends on D142808
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D142843
LWG3839 range_formatter's set_separator, set_brackets, and
underlying functions should be noexcept
Adds tests for:
template<ranges::input_range R, class charT>
struct range-default-formatter<range_format::sequence, R, charT>
These were missing, the format functions tests for the sequences
are already present.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D144286
https://wg21.link/LWG2444 updated the comparison complexity of
std:sort_heap to be at most 2N log (N) where N == last - first. In the
current implementation, we invoke __pop_heap exactly N-1 times. In each
call to __pop_heap, we first go down the heap from first to possibly
last in the function __floyd_sift_down. Then, we possibly go back up in
the function __sift_up.
In the function __floyd_sift_down, there is loop in which one comparison
is made in each iteration. The loop runs till __child becomes greater
than (__len - 2) / 2. __child starts at 0 and it is at least set to 2 *
__child + 1 on each iteration. Thus, after k iterations, __child will
be at least 2^k - 1. After log(N) iterations, __child >= 2^(log(N)) -
1 = N - 1 > (__len - 2) / 2. This means that the while loop in the
function __floyd_sift_down would perform at most log(N) comparisons on
each invocation.
In the function __sift_up, there is one comparison made that will almost
always occur. After that there is a do-while loop. The comparison
function is invoked once in each iteration. In the worst case, the loop
will run till __len goes down to zero. It can start from (N-3)/2. In
each iteration, __len goes down to (__len-1) / 2. After k iterations,
__len will be at most (N - 2^(k+1) -1) / 2^(k+1). Thus, __len will
become when (N-2^(k+1)-1) < 2^(k+1) i.e. N < 2^(k+2) + 1. This means
at most log(N) - 1 iterations for the loop. So in total at most log(N)
comparison will be performed in __sift_up.
So overall for each iteration of the loop in __pop_heap, there will at
most 2 log(N) comparisons. So, the total number of comparisons is
at most 2 N log(N).
We also updated the test sort.heap/complexity.pass.cpp to test for the
number of operations.
Differential Revision: https://reviews.llvm.org/D144538
LWG3103 Errors in taking subview of span should be ill-formed where possible
Note that the real work was already done before, including tests.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D143432
`views::as_rvalue` was implemented in D137637, but we forgot to set the feature test macro.
Fixes#60986.
Reviewed By: Mordante, #libc
Spies: libcxx-commits, arichardson
Differential Revision: https://reviews.llvm.org/D144781
These macros are intended to replace the macros in rapid-cxx-test.h.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D142808
The `basic_string_view` constructor accepting a contiguous range rejects
converting between `basic_string_view` even when only the trait types vary.
This prevents conversions for converting from `basic_string_view<C, T1>` and
`basic_string<C, T1, A>` to `basic_string_view<C, T2>`. Recently, this
constructor was made `explicit`, so there's no reason to really forbid this
conversion anymore.
Relax the restriction that the trait types need to match in this constructor.
Differential Revision: https://reviews.llvm.org/D143972
Partially implements:
- P1361 Integration of chrono with text formatting
- P2372 Fixing locale handling in chrono formatters
- P1466 Miscellaneous minor fixes for chrono
Depends on D137022
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D139771
Instead of destroying the object with allocator::destroy, we must
call its destructor directly. As a fly-by also mark LWG3008 as
fixed since it is handled by our implementation.
This was pointed out by Tim Song in https://reviews.llvm.org/D140913.
Differential Revision: https://reviews.llvm.org/D143791
The implementation makes use of the freedom added by LWG 3410. We have
two variants of this algorithm:
* a fast path for random access iterators: This fast path computes the
maximum number of loop iterations up-front and does not compare the
iterators against their limits on every loop iteration.
* A basic implementation for all other iterators: This implementation
compares the iterators against their limits in every loop iteration.
However, it still takes advantage of the freedom added by LWG 3410 to
avoid unnecessary additional iterator comparisons, as originally
specified by P1614R2.
https://godbolt.org/z/7xbMEen5e shows the benefit of the fast path:
The hot loop generated of `lexicographical_compare_three_way3` is
more tight than for `lexicographical_compare_three_way1`. The added
benchmark illustrates how this leads to a 30% - 50% performance
improvement on integer vectors.
Implements part of P1614R2 "The Mothership has Landed"
Fixes LWG 3410 and LWG 3350
Differential Revision: https://reviews.llvm.org/D131395
