Avoid relying on `iterator_traits` and instead deduce the return type of
dereferencing the iterator. Additionally, add a static check to reject
iterators with incorrect `iterator_traits` at compile time.
Differential Revision: https://reviews.llvm.org/D130538
- for all algorithms taking more than one range, add a `robust` test to
check the case where the ranges have different value types and the
given projections are different, with each projection applying to
a different value type;
- fix `ranges::include` to apply the correct projection to each range.
Differential Revision: https://reviews.llvm.org/D130515
This adds a C++20-version of `reverse_iterator` which doesn't SFINAE away the operators for use inside the classic STL algorithms. Pre-C++20 `_AlgRevIter` is just an alias for `reverse_iterator`.
Reviewed By: var-const, #libc
Spies: huixie90, libcxx-commits
Differential Revision: https://reviews.llvm.org/D128864
The return type was specified incorrectly for proxy iterators that
define `reference` to be a class that implicitly converts to
`value_type`. `__iter_move` would end up returning an object of type
`reference` which would then implicitly convert to `value_type`; thus,
the function will return a `value_type&&` rvalue reference to the local
temporary.
Differential Revision: https://reviews.llvm.org/D130197
Change the mechanism in `iterator_operations.h` to pass around a generic
policy tag indicating whether an internal function is being invoked from
a "classic" STL algorithm or a ranges algorithm. `IterOps` is now
a template class specialized on the policy tag.
The advantage is that this mechanism is more generic and allows defining
arbitrary conditions in a clean manner.
Also add a few more iterator functions to `IterOps`.
Differential Revision: https://reviews.llvm.org/D129390
- create the headers (but not include them from `<algorithm>`);
- define the niebloid and its member functions with the right signatures
(as no-ops);
- make sure all the right headers are included that are required by each
algorithm's signature;
- update `CMakeLists.txt` and the module map;
- create the test files with the appropriate synopses.
The synopsis in `<algorithm>` is deliberately not updated because that
could be taken as a readiness signal. The new headers aren't included
from `<algorithm>` for the same reason.
Differential Revision: https://reviews.llvm.org/D129549
implement `std::ranges::set_intersection` by reusing the classic `std::set_intersenction`
added unit tests
Differential Revision: https://reviews.llvm.org/D129233
Also, improve the test for nasty macros to define min and max, so this
will be caught in the future.
Differential Revision: https://reviews.llvm.org/D128655
This patch also adds a new optimization to `std::move`. It unwraps three `reverse_iterator`s if the wrapped iterator is a `contiguous_iterator` and the iterated type is trivially_movable. This allows us to simplify `ranges::move_backward` to a forward to `std::move` without any pessimization.
Reviewed By: var-const, #libc
Spies: libcxx-commits, mgorny
Differential Revision: https://reviews.llvm.org/D126616
Simplify the implementation of `std::copy` and `std::move` by using `__unwrap_iter` and `__rewrap_iter` to unwrap and rewrap `reverse_iterator<reverse_iterator<Iter>>` instead of specializing `__copy_impl` and `__move_impl`.
Reviewed By: ldionne, #libc
Spies: wenlei, libcxx-commits
Differential Revision: https://reviews.llvm.org/D127049
The flexibility around extern template instantiation declarations in
libc++ result in a very complicated model, especially when support for
slightly different configurations (like the debug mode or assertions
in the dylib) are taken into account. That results in unexpected bugs
like http://llvm.org/PR50534 (and there have been multiple similar
bugs in the past, notably around the debug mode).
This patch gets rid of the _LIBCPP_DISABLE_EXTERN_TEMPLATE knob, which
I don't think is fundamental. Indeed, the motivation for that knob was to
avoid taking a dependency on the library, however that can be done better
by linking against the static library instead. And in fact, some parts of
the headers will always depend on things defined in the library, which
defeats the original goal of _LIBCPP_DISABLE_EXTERN_TEMPLATE.
Differential Revision: https://reviews.llvm.org/D103960
