An issue with `operator()` was found during the implementation of https://reviews.llvm.org/D132268.
This patch aims to resolve the issues by updating the operator to use perfect forwarding.
The original motivation for `three_way_comp_ref_type` is given in: https://reviews.llvm.org/D131395
`three_way_comp_ref_type`'s implementation is inspired by `comp_ref_type`, which has two overloads:
```
template <class _Tp, class _Up>
bool operator()(const _Tp& __x, const _Up& __y);
template <class _Tp, class _Up>
bool operator()(_Tp& __x, _Up& __y);
```
`__debug_three_way_comp` is missing the first overload and also declares the typealias`_three_way_comp_ref_type ` incorrectly.
Reviewed By: #libc, philnik
Differential Revision: https://reviews.llvm.org/D150188
This also removes some tests which we have grouped together into robust_from_*.pass.cpp tests.
Specifically, checking that
- `ranges::dangling` is returned is done in `libcxx/test/std/algorithms/ranges_robust_against_dangling.pass.cpp`
- `std::invoke` is used is done in `libcxx/test/std/algorithms/ranges_robust_against_omitting_invoke.pass.cpp`.
- implicit conversion to bool works is done in `libcxx/test/std/algorithms/ranges_robust_against_nonbool_predicates.pass.cpp`
Checking the comparison order is invalid because the `operator==` isn't symmetric.
Checking what the exact type of `operator==` is, is invalid because comparing the same object has to yield the same results if the objects are not modified.
Reviewed By: ldionne, #libc
Spies: EricWF, libcxx-commits
Differential Revision: https://reviews.llvm.org/D150588
This removes the need for a custom libc++ build to have a basic set of PSTL algorithms.
Reviewed By: ldionne, #libc
Spies: miyuki, libcxx-commits, arichardson
Differential Revision: https://reviews.llvm.org/D149624
Instead of writing something like `XFAIL: use_system_cxx_lib && target=...`
to XFAIL back-deployment tests, introduce named Lit features like
`availability-shared_mutex-missing` to represent those. This makes the
XFAIL annotations leaner, and solves the problem of XFAIL comments
potentially getting out of sync. This would also make it easier for
another vendor to add their own annotations to the test suite by simply
changing how the feature is defined for their OS releases, instead
of having to modify hundreds of tests to add repetitive annotations.
This doesn't touch *all* annotations -- only annotations that were widely
duplicated are given named features (e.g. when filesystem or shared_mutex
were introduced). I still think it probably doesn't make sense to have a
named feature for every single fix we make to the dylib.
This is in essence a revert of 2659663, but since then the test suite
has changed significantly. Back when I did 2659663, the configuration
files we have for the test suite right now were being bootstrapped and
it wasn't clear how to provide these features for back-deployment in
that context. Since then, we have a streamlined way of defining these
features in `features.py` and that doesn't impact the ability for a
configuration file to stay minimal.
The original motivation for this change was that I am about to propose
a change that would touch essentially all XFAIL annotations for back-deployment
in the test suite, and this greatly reduces the number of lines changed
by that upcoming change, in addition to making the test suite generally
better.
Differential Revision: https://reviews.llvm.org/D146359
This has been done using the following commands
find libcxx/test -type f -exec perl -pi -e 's|^([^/]+?)((?<!::)ptrdiff_t)|\1std::\2|' \{} \;
find libcxx/test -type f -exec perl -pi -e 's|^([^/]+?)((?<!::)max_align_t)|\1std::\2|' \{} \;
The std module doesn't export declarations in the global namespaace.,
This is a preparation for that module.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D146550
This has been done using the following command
find libcxx/test -type f -exec perl -pi -e 's|^([^/]+?)((?<!::)size_t)|\1std::\2|' \{} \;
And manually removed some false positives in std/depr/depr.c.headers.
The `std` module doesn't export `::size_t`, this is a preparation for that module.
Reviewed By: ldionne, #libc, EricWF, philnik
Differential Revision: https://reviews.llvm.org/D146088
Don't forward to `min_element` for small types that are trivially copyable, and instead use a naive loop that keeps track of the smallest element (as opposed to an iterator to the smallest element). This allows the compiler to vectorize the loop in some cases.
Reviewed By: #libc, ldionne
Spies: ldionne, libcxx-commits
Differential Revision: https://reviews.llvm.org/D143596
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
First, fix a collision with the Point type from MacTypes.h, which was
reported on Slack, 2022-07-31: https://cpplang.slack.com/archives/C2X659D1B/p1659284691275889
Second, rename the meta:: namespace to types::. OSX's "/usr/include/ncurses.h"
defines a `meta` function, and is (for some reason) included in
"<SDK>/usr/include/module.modulemap", so that identifier is off-limits
for us to use in anything that compiles with -fmodules:
libcxx/test/support/type_algorithms.h:16:11: error: redefinition of 'meta' as different kind of symbol
namespace meta {
^
<SDK>/usr/include/ncurses.h:603:28: note: previous definition is here
extern NCURSES_EXPORT(int) meta (WINDOW *,bool); /* implemented */
^
Finally, add a CI configuration for modules on OS X to make sure it
does not regress.
Differential Revision: https://reviews.llvm.org/D144915
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
`ranges.transform.binary.pass.cpp` took ~25s to compile. `ranges.transform.binary.range.pass.cpp` and `ranges.transform.binary.iterator.pass.cpp` take ~13s each.
Reviewed By: ldionne, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D142183
This has multiple benefits:
- The optimizations are also performed for the `ranges::` versions of the algorithms
- Code duplication is reduced
- it is simpler to add this optimization for other segmented iterators,
like `ranges::join_view::iterator`
- Algorithm code is removed from `<deque>`
Reviewed By: ldionne, huixie90, #libc
Spies: mstorsjo, sstefan1, EricWF, libcxx-commits, mgorny
Differential Revision: https://reviews.llvm.org/D132505
`ranges.transform.pass.cpp` takes ~42s to run on my machine, `ranges.transform.binary.pass.cpp` takes ~26s and `ranges.transform.unary.pass.cpp` takes ~2s.
Reviewed By: ldionne, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D141965
This reverts commit a6e1080b87db8fbe0e1afadd96af5a3c0bd5e279.
Fix the conditions when the `memmove` optimization can be applied and refactor them out into a reusable type trait, fix and significantly expand the tests.
Differential Revision: https://reviews.llvm.org/D139235
C++ constexpr allows a non-constant-expresssion lvalue to be used in a constant expression if it's not subject to lvalue-to-rvalue conversion. Subtly, this means you can make a constant-expression copy of a non-constant-expression object of empty type since the copy constructor doesn't perform lvalue-to-rvalue conversion. MSVC has had bugs with this usage forever, which will hopefully finally be mashed implementing C++23's relaxation on the use of pointers and references in constant expressions.
There's no need for this particular test to use this particular constexpr feature, we can simply make the predicates constant expressions.
Differential Revision: https://reviews.llvm.org/D141336
Per our policy, the latest released AppleClang has been 14 for a while,
so libc++ is removing support for AppleClang 13. Our CI bots have been
moved to AppleClang 14 a few weeks ago.
Differential Revision: https://reviews.llvm.org/D138685
We currently call a lot of functions with the same list of types. To avoid forgetting any of them, this patch adds type_lists and utilities for it. Specifically, it adds
- `type_list` - This is just a list of types
- `concatenate` - This allows concatenating type_lists
- `for_each` - Iterate over a type_list
Reviewed By: ldionne, #libc
Spies: jloser, EricWF, libcxx-commits
Differential Revision: https://reviews.llvm.org/D137476
This mirrors what we have done in the classic algorithms
Reviewed By: ldionne, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D137186
