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
This fixes the remaining errors when building the llvm-project
with `LLVM_ENABLE_MODULES=ON` (and `LLVM_ENABLE_LOCAL_SUBMODULE_VISIBILITY=ON`,
which currently is the LLVM default).
Previously this would fail in the `CXX_SUPPORTS_MODULES` check.
Differential Revision: https://reviews.llvm.org/D141833
This reverts commit a6e1080b87.
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
While it's not necessary to qualify calls to `declval` it makes error messages very crypric if the declaration isn't reachable anymore
For example:
```
/home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__chrono/duration.h:53:66: error: no type named 'type' in 'std::common_type<long, long>'
typedef chrono::duration<typename common_type<_Rep1, _Rep2>::type,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~
/home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__type_traits/common_type.h:107:14: note: in instantiation of template class 'std::common_type<std::chrono::duration<long, std::ratio<3600, 1>>, std::chrono::duration<long, std::ratio<3600, 1>>>' requested here
: public common_type<_Tp, _Tp> {};
^
/home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__chrono/duration.h:279:58: note: in instantiation of template class 'std::common_type<std::chrono::duration<long, std::ratio<3600, 1>>>' requested here
_LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR typename common_type<duration>::type operator+() const {return typename common_type<duration>::type(*this);}
^
/home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__chrono/duration.h:308:54: note: in instantiation of template class 'std::chrono::duration<long, std::ratio<3600, 1>>' requested here
typedef duration< int, ratio_multiply<ratio<24>, hours::period>> days;
^
/home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__chrono/duration.h:280:81: error: no type named 'type' in 'std::common_type<std::chrono::duration<long, std::ratio<3600, 1>>>'
_LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR typename common_type<duration>::type operator-() const {return typename common_type<duration>::type(-__rep_);}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~
/home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__chrono/duration.h:308:54: note: in instantiation of template class 'std::chrono::duration<long, std::ratio<3600, 1>>' requested here
typedef duration< int, ratio_multiply<ratio<24>, hours::period>> days;
^
/home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__chrono/duration.h:53:66: error: no type named 'type' in 'std::common_type<int, int>'
typedef chrono::duration<typename common_type<_Rep1, _Rep2>::type,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~
/home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__type_traits/common_type.h:107:14: note: in instantiation of template class 'std::common_type<std::chrono::duration<int, std::ratio<86400, 1>>, std::chrono::duration<int, std::ratio<86400, 1>>>' requested here
: public common_type<_Tp, _Tp> {};
^
/home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__chrono/duration.h:279:58: note: in instantiation of template class 'std::common_type<std::chrono::duration<int, std::ratio<86400, 1>>>' requested here
_LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR typename common_type<duration>::type operator+() const {return typename common_type<duration>::type(*this);}
^
/home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__chrono/duration.h:309:55: note: in instantiation of template class 'std::chrono::duration<int, std::ratio<86400, 1>>' requested here
typedef duration< int, ratio_multiply<ratio<7>, days::period>> weeks;
^
19 similar errors omitted
```
changes with qualification added to:
```
While building module 'std' imported from /home/nikolask/llvm-projects/libcxx/libcxx/test/std/utilities/meta/meta.trans/meta.trans.other/common_type.pass.cpp:13:
In file included from <module-includes>:17:
In file included from /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/math.h:309:
In file included from /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/limits:107:
In file included from /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/type_traits:432:
In file included from /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__type_traits/common_reference.h:13:
/home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__type_traits/common_type.h:28:43: error: declaration of 'declval' must be imported from module 'std.utility.__utility.declval' before it is required
using __cond_type = decltype(false ? std::declval<_Tp>() : std::declval<_Up>());
^
/home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__utility/declval.h:30:34: note: declaration here is not visible
decltype(std::__declval<_Tp>(0)) declval() _NOEXCEPT;
^
/home/nikolask/llvm-projects/libcxx/libcxx/test/std/utilities/meta/meta.trans/meta.trans.other/common_type.pass.cpp:13:10: fatal error: could not build module 'std'
#include <functional>
~~~~~~~~^
2 errors generated.
```
Reviewed By: ldionne, Mordante, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D130854
These "implementation detail" function templates were already
hidden and have no specializations in the dylib, so they seem like they can safely
use _LIBCPP_HIDE_FROM_ABI instead and have the abi tags applied as well.
Seems some of these got over looked (e.g. D129823) in various places, and they
won't be flagged by the new checks added in D129968, as they were
already hidden.
Reviewed by: ldionne
Differential Revision: https://reviews.llvm.org/D135504
There are a handful of standard library types that are intended
to support CTAD but don't need any explicit deduction guides to
do so.
This patch adds a dummy deduction guide to those types to suppress
-Wctad-maybe-unsupported (which gets emitted in user code).
This is a re-application of the original patch by Eric Fiselier in
fcd549a7d8 which had been reverted due to reasons lost at this point.
I also added the macro to a few more types. Reviving this patch was
prompted by the discussion on https://llvm.org/D133425.
Differential Revision: https://reviews.llvm.org/D133535
Instead of using `reverse_iterator`, share the optimization between the 4 algorithms. The key observation here that `memmove` applies to both `copy` and `move` identically, and to their `_backward` versions very similarly. All algorithms now follow the same pattern along the lines of:
```
if constexpr (can_memmove<InIter, OutIter>) {
memmove(first, last, out);
} else {
naive_implementation(first, last, out);
}
```
A follow-up will delete `unconstrained_reverse_iterator`.
This patch removes duplication and divergence between `std::copy`, `std::move` and `std::move_backward`. It also improves testing:
- the test for whether the optimization is used only applied to `std::copy` and, more importantly, was essentially a no-op because it would still pass if the optimization was not used;
- there were no tests to make sure the optimization is not used when the effect would be visible.
Differential Revision: https://reviews.llvm.org/D130695
This was discussed on Discord with the consensus that we should rename the macros.
Reviewed By: ldionne, Mordante, var-const, avogelsgesang, jloser, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D131498
When we ship LLVM 16, <ranges> won't be considered experimental anymore.
We might as well do this sooner rather than later.
Differential Revision: https://reviews.llvm.org/D132151
Also fix `ranges::stable_sort` and `ranges::inplace_merge` to support
proxy iterators now that their internal implementations can correctly
dispatch `rotate`.
Differential Revision: https://reviews.llvm.org/D130758
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
- P1252 ("Ranges Design Cleanup") -- deprecate
`move_iterator::operator->` starting from C++20; add range comparisons
to the `<functional>` synopsis. This restores
`move_iterator::operator->` that was incorrectly deleted in D117656;
it's still defined in the latest draft, see
http://eel.is/c++draft/depr.move.iter.elem. Note that changes to
`*_result` types from 6.1 in the paper are no longer relevant now that
these types are aliases;
- P2106 ("Alternative wording for GB315 and GB316") -- add a few
`*_result` types to the synopsis in `<algorithm>` (some algorithms are
not implemented yet and thus some of the proposal still cannot be
marked as done);
Also mark already done issues as done (or as nothing to do):
- P2091 ("Fixing Issues With Range Access CPOs") was already implemented
(this patch adds tests for some ill-formed cases);
- LWG 3247 ("`ranges::iter_move` should perform ADL-only lookup of
`iter_move`") was already implemented;
- LWG 3300 ("Non-array ssize overload is underconstrained") doesn't
affect the implementation;
- LWG 3335 ("Resolve C++20 NB comments US 273 and GB 274") was already
implemented;
- LWG 3355 ("The memory algorithms should support move-only input
iterators introduced by P1207") was already implemented (except for
testing).
Differential Revision: https://reviews.llvm.org/D126053
Previously, we'd use raw pointers when the debug mode was enabled,
which means we wouldn't get out-of-range checking with std::span's
iterators.
This patch introduces a new class called __bounded_iter which can
be used to wrap iterators and make them carry around bounds-related
information. This allows iterators to assert when they are dereferenced
outside of their bounds.
As a fly-by change, this commit removes the _LIBCPP_ABI_SPAN_POINTER_ITERATORS
knob. Indeed, not using a raw pointer as the iterator type is useful to
avoid users depending on properties of raw pointers in their code.
This is an alternative to D127401.
Differential Revision: https://reviews.llvm.org/D127418
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 debug mode has been broken pretty much ever since it was shipped
because it was possible to enable the debug mode in user code without
actually enabling it in the dylib, leading to ODR violations that
caused various kinds of failures.
This commit makes the debug mode a knob that is configured when
building the library and which can't be changed afterwards. This is
less flexible for users, however it will actually work as intended
and it will allow us, in the future, to add various kinds of checks
that do not assume the same ABI as the normal library. Furthermore,
this will make the debug mode more robust, which means that vendors
might be more tempted to support it properly, which hasn't been the
case with the current debug mode.
This patch shouldn't break any user code, except folks who are building
against a library that doesn't have the debug mode enabled and who try
to enable the debug mode in their code. Such users will get a compile-time
error explaining that this configuration isn't supported anymore.
In the future, we should further increase the granularity of the debug
mode checks so that we can cherry-pick which checks to enable, like we
do for unspecified behavior randomization.
Differential Revision: https://reviews.llvm.org/D122941
Instead of providing two different constructors for iterators that
support the debug mode, provide a single constructor but leave the
container parameter unused when the debug mode is not enabled.
This allows simplifying all the call sites to unconditionally pass
the container, which removes a bunch of duplication in the container's
implementation.
Note that this patch does add some complexity to std::span, however
that is only because std::span has the ability to use raw pointers
as iterators instead of __wrap_iter. In retrospect, I believe it was
a mistake to provide that capability, and so it will be removed in a
future patch, along with the complexity added by this patch.
Differential Revision: https://reviews.llvm.org/D126993
In D122982 I accidentally disabled the memmove optimization. This re-enables it and adds more cases where copy forwards to memmove.
Fixes https://github.com/llvm/llvm-project/issues/33687
Reviewed By: var-const, #libc, ldionne
Spies: pkasting, ayzhao, dcheng, xbolva00, libcxx-commits
Differential Revision: https://reviews.llvm.org/D124328
We require move semantics in C++03 anyways, so let's enable them for the containers.
Reviewed By: ldionne, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D123802
There are many more instances of this pattern, but I chose to limit this change to .rst files (docs), anything in libcxx/include, and string literals. These have the highest chance of being seen by end users.
Reviewed By: #libc, Mordante, martong, ldionne
Differential Revision: https://reviews.llvm.org/D124708
