This test fails in the Fedora RPM build (but not elsewhere, for unknown
reasons). The warning is correct, we're passing a null pointer.
* testsuite/tr1/8_c_compatibility/cstdlib/functions.cc: Do not pass
a null pointer to functions with nonnull(1) attribute.
This adds a tests that verifies taking the split_view of a non-forward range
works correctly. Doing so revealed a typo in one of _OuterIter's constructors.
It also revealed that the default constructor of
__gnu_test::test_range::iterator misbehaves, because by delegating to
Iter<T>(nullptr, nullptr) we perform a null-pointer deref at runtime in
input_iterator_wrapper's constructor due to the ITERATOR_VERIFY check therein.
Instead of delegating to this constructor it seems we can just inherit the
protected default constructor, which does not contain this ITERATOR_VERIFY
check.
libstdc++-v3/ChangeLog:
* include/std/ranges (split_view::_OuterIter::_OuterIter): Typo fix,
'address' -> 'std::__addressof'.
* testsuite/std/ranges/adaptors/split.cc: Test taking the split_view of
a non-forward input_range.
* testsuite/util/testsuite_iterators.h (output_iterator_wrapper): Make
default constructor protected instead of deleted, like with
input_iterator_wrapper.
(test_range::iterator): Add comment explaining that this type is used
only when the underlying wrapper is input_iterator_wrapper or
output_iterator_wrapper. Remove delegating defaulted constructor so
that the inherited default constructor is used instead.
... a call to ranges::begin on an input range.
This implements LWG 3286. The new wording for the single-argument constructor
for subrange is implemented by splitting the constructor into two delegating
constructors, one constrained by _S_store_size and the other by !_S_store_size.
Tested on x86_64-pc-linux-gnu, both added tests fail before the patch and pass
with the patch.
libstdc++-v3/ChangeLog:
LWG 3286 ranges::size is not required to be valid after a call to
ranges::begin on an input range
* include/std/ranges (subrange::subrange): Split single-argument
constructor into two, one constrained by _S_store_size and another by
!_S_store_size.
(take_view::begin): Call size() before calling ranges::begin(_M_base).
* testsuite/std/ranges/adaptors/lwg3286.cc: New test.
* testsuite/std/ranges/subrange/lwg3286.cc: New test.
Also introduce the _M_i_current() accessors to solve the problem of
access to the private member of _OuterIter from the iter_move and
iter_swap overloads (which are only friends of _InnerIter not
_OuterIter).
* include/std/ranges (transform_view::_Iterator::__iter_move): Remove.
(transform_view::_Iterator::operator*): Add noexcept-specifier.
(transform_view::_Iterator::iter_move): Inline __iter_move body here.
(split_view::_OuterIter::__current): Add noexcept.
(split_view::_InnerIter::__iter_swap): Remove.
(split_view::_InnerIter::__iter_move): Remove.
(split_view::_InnerIter::_M_i_current): New accessors.
(split_view::_InnerIter::__at_end): Use _M_i_current().
(split_view::_InnerIter::operator*): Likewise.
(split_view::_InnerIter::operator++): Likewise.
(iter_move(const _InnerIter&)): Likewise.
(iter_swap(const _InnerIter&, const _InnerIter&)): Likewise.
* testsuite/std/ranges/adaptors/split.cc: Check noexcept-specifier
for iter_move and iter_swap on split_view's inner iterator.
The 24_iterators/ostream_iterator/1.cc test uses VERIFY and so is
obviously meant to have been run, not just compiled.
* testsuite/23_containers/unordered_set/allocator/ext_ptr.cc: Add
comment explaining multiple dg-do directives.
* testsuite/24_iterators/ostream_iterator/1.cc: Fix do-do directive
so test is run as well as compiled.
The filesystem::path::operator+= and filesystem::path::concat functions
operate directly on the native format of the path and so can cause a
path to mutate to a completely different type.
For Windows combining a filename "x" with a filename ":" produces a
root-name "x:". Similarly, a Cygwin root-directory "/" combined with a
root-directory and filename "/x" produces a root-name "//x".
Before this patch the implemenation didn't support those kind of
mutations, assuming that concatenating two filenames would always
produce a filename and concatenating with a root-dir would still have a
root-dir.
This patch fixes it simply by checking for the problem cases and
creating a new path by re-parsing the result of the string
concatenation. This is slightly suboptimal because the argument has
already been parsed if it's a path, but more importantly it doesn't
reuse any excess capacity that the path object being modified might
already have allocated. That can be fixed later though.
PR libstdc++/94063
* src/c++17/fs_path.cc (path::operator+=(const path&)): Add kluge to
handle concatenations that change the type of the first component.
(path::operator+=(basic_string_view<value_type>)): Likewise.
* testsuite/27_io/filesystem/path/concat/94063.cc: New test.
The converting constructor of join_view::_Sentinel<true> needs to be able to
access the private members of join_view::_Sentinel<false>.
libstdc++-v3/ChangeLog:
* include/std/ranges (join_view::_Sentinel<_Const>): Befriend
join_view::_Sentinel<!_Const>.
* testsuite/std/ranges/adaptors/join.cc: Augment test.
This works around PR 93978 by avoiding having to instantiate the body of
ranges::empty() when checking the constraints of view_interface::operator
bool(). When ranges::empty() has an auto return type, then we must instantiate
its body in order to determine whether the requires expression {
ranges::empty(_M_derived()); } is well-formed. But this means instantiating
view_interface::empty() and hence view_interface::_M_derived(), all before we've
yet deduced the return type of join_view::end(). (The reason
view_interface::operator bool() is needed in join_view::end() in the first place
is because in this function we perform direct initialization of
join_view::_Sentinel from a join_view, and so we try to find a conversion
sequence from the latter to the former that goes through this conversion
operator.)
Giving ranges::empty() a concrete return type of bool should be safe according
to [range.prim.empty]/4 which says "whenever ranges::empty(E) is a valid
expression, it has type bool."
This fixes the test case in PR 93978 when compiling without -Wall, but with -Wall
the test case still fails due to the issue described in PR c++/94038, I think.
I still don't quite understand why the test case doesn't fail without -O.
libstdc++-v3/ChangeLog:
PR libstdc++/93978
* include/bits/range_access.h (__cust_access::_Empty::operator()):
Declare return type to be bool instead of auto.
* testsuite/std/ranges/adaptors/93978.cc: New test.
When the target doesn't define PTHREAD_RWLOCK_INITIALIZER we use a
wrapper around pthread_wrlock_init, but the wrapper only takes one
argument and we try to call it with two.
This went unnnoticed on most targets because they do define the
PTHREAD_RWLOCK_INITIALIZER macro, but it causes a bootstrap failure on
darwin8.
PR libstdc++/93244
* include/std/shared_mutex [!PTHREAD_RWLOCK_INITIALIZER]
(__shared_mutex_pthread::__shared_mutex_pthread()): Remove incorrect
second argument to __glibcxx_rwlock_init.
* testsuite/30_threads/shared_timed_mutex/94069.cc: New test.
The checks for PR 93244 don't actually pass on Windows (which is the
target where the bug is present) because of a different bug, PR 94063.
This adjusts the tests to not be affected by 94063 so that they verify
that 93244 was fixed.
PR libstdc++/93244
* testsuite/27_io/filesystem/path/generic/generic_string.cc: Adjust
test to not fail due to PR 94063.
* testsuite/27_io/filesystem/path/generic/utf.cc: Likewise.
* testsuite/27_io/filesystem/path/generic/wchar_t.cc: Likewise.
There's a -Wunused-but-set-variable warning in operations/all.cc which
can be fixed with [[maybe_unused]].
The statements in operations/copy.cc give -Wunused-value warnings. I
think I meant to use |= rather than !=.
And operations/file_size.cc gets -Wsign-compare warnings.
* testsuite/27_io/filesystem/operations/all.cc: Mark unused variable.
* testsuite/27_io/filesystem/operations/copy.cc: Fix typo.
* testsuite/experimental/filesystem/operations/copy.cc: Likewise.
* testsuite/27_io/filesystem/operations/file_size.cc: Use correct type
for return value, and in comparison.
* testsuite/experimental/filesystem/operations/file_size.cc: Likewise.
I don't think this is actually required to compile, because using
operator<< without a definition of the ostream doesn't seem valid to me.
But it's easy to make it work.
PR libstdc++/94051
* include/std/string_view: Include <bits/ostream_insert.h>.
* testsuite/21_strings/basic_string_view/inserters/94051.cc: New test.
When deciding whether to perform the memset optimization in ranges::fill_n, we
were crucially neglecting to check that the output pointer's value type is a
byte type. This patch adds such a check to the problematic condition in
ranges::fill_n.
At the same time, this patch relaxes the overly conservative
__is_byte<_Tp>::__value check that requires the fill type be a byte type. It's
overly conservative because it means we won't enable the memset optimization in
the following example
char c[100];
ranges::fill(c, 37);
because the fill type is deduced to be int here. Rather than requiring that the
fill type be a byte type, it seems safe to just require the fill type be an
integral type, which is what this patch does.
libstdc++-v3/ChangeLog:
PR libstdc++/94017
* include/bits/ranges_algobase.h (__fill_n_fn::operator()): Refine
condition for when to use memset, making sure to additionally check that
the output pointer's value type is a non-volatile byte type. Instead of
requiring that the fill type is a byte type, just require that it's an
integral type.
* testsuite/20_util/specialized_algorithms/uninitialized_fill/94017.cc:
New test.
* testsuite/20_util/specialized_algorithms/uninitialized_fill_n/94017.cc:
New test.
* testsuite/25_algorithms/fill/94013.cc: Uncomment part that was blocked
by PR 94017.
* testsuite/25_algorithms/fill/94017.cc: New test.
* testsuite/25_algorithms/fill_n/94017.cc: New test.
This adds support for move-only input iterators in the ranges::unitialized_*
algorithms defined in <memory>, as per LWG 3355. The only changes needed are to
add calls to std::move in the appropriate places and to use operator- instead of
ranges::distance because the latter cannot be used with a move-only iterator
that has a sized sentinel, as is the case here. (This issue with
ranges::distance is LWG 3392.)
libstdc++-v3/ChangeLog:
LWG 3355 The memory algorithms should support move-only input iterators
introduced by P1207
* include/bits/ranges_uninitialized.h
(__uninitialized_copy_fn::operator()): Use std::move to avoid attempting
to copy __ifirst, which could be a move-only input iterator. Use
operator- instead of ranges::distance to compute distance from a sized
sentinel.
(__uninitialized_copy_n_fn::operator()): Likewise.
(__uninitialized_move_fn::operator()): Likewise.
(__uninitialized_move_n_fn::operator()): Likewise.
(__uninitialized_destroy_fn::operator()): Use std::move to avoid
attempting to copy __first.
(__uninitialized_destroy_n_fn::operator()): Likewise.
* testsuite/20_util/specialized_algorithms/destroy/constrained.cc:
Augment test.
* .../specialized_algorithms/uninitialized_copy/constrained.cc:
Likewise.
* .../specialized_algorithms/uninitialized_move/constrained.cc:
Likewise.
This adds a testsuite range type whose end() is a sized sentinel to
<testsuite_iterators.h>, which will be used in the tests that verify LWG 3355.
libstdc++-v3/ChangeLog:
* testsuite/util/testsuite_iterators.h (test_range::get_iterator): Make
protected instead of private.
(test_sized_range_sized_sent): New.
This adds a move-only testsuite iterator wrapper to <testsuite_iterators.h>
which will be used in the tests for LWG 3355. The tests for LWG 3389 and 3390
are adjusted to use this new iterator wrapper.
libstdc++-v3/ChangeLog:
* testsuite/util/testsuite_iterators.h (input_iterator_wrapper_nocopy):
New testsuite iterator.
* testsuite/24_iterators/counted_iterator/lwg3389.cc: Use it.
* testsuite/24_iterators/move_iterator/lwg3390.cc: Likewise.
Several algorithms check the is_trivially_copyable trait to decide
whether to dispatch to memmove or memcmp as an optimization. Since
r271435 (CWG DR 2094) the trait is true for volatile-qualified scalars,
but we can't use memmove or memcmp when the type is volatile. We need to
also check for volatile types.
This is complicated by the fact that in C++20 (but not earlier standards)
iterator_traits<volatile T*>::value_type is T, so we can't just check
whether the value_type is volatile.
The solution in this patch is to introduce new traits __memcpyable and
__memcmpable which combine into a single trait the checks for pointers,
the value types being the same, and the type being trivially copyable
but not volatile-qualified.
PR libstdc++/94013
* include/bits/cpp_type_traits.h (__memcpyable, __memcmpable): New
traits to control when to use memmove and memcmp optimizations.
(__is_nonvolatile_trivially_copyable): New helper trait.
* include/bits/ranges_algo.h (__lexicographical_compare_fn): Do not
use memcmp optimization with volatile data.
* include/bits/ranges_algobase.h (__equal_fn): Use __memcmpable.
(__copy_or_move, __copy_or_move_backward): Use __memcpyable.
* include/bits/stl_algobase.h (__copy_move_a2): Use __memcpyable.
(__copy_move_backward_a2): Likewise.
(__equal_aux1): Use __memcmpable.
(__lexicographical_compare_aux): Do not use memcmp optimization with
volatile data.
* testsuite/25_algorithms/copy/94013.cc: New test.
* testsuite/25_algorithms/copy_backward/94013.cc: New test.
* testsuite/25_algorithms/equal/94013.cc: New test.
* testsuite/25_algorithms/fill/94013.cc: New test.
* testsuite/25_algorithms/lexicographical_compare/94013.cc: New test.
* testsuite/25_algorithms/move/94013.cc: New test.
* testsuite/25_algorithms/move_backward/94013.cc: New test.
The new 25_algorithms/lexicographical_compare/93972.cc test fails on
targets where char is unsigned, revealing an existing regression with
the std::__memcmp helper that had gone unnoticed in
std::lexicographical_compare. When comparing char and unsigned char, the
memcmp optimisation is enabled, but the new std::__memcmp function fails
to compile for mismatched types.
PR libstdc++/93972
* include/bits/stl_algobase.h (__memcmp): Allow pointer types to
differ.
* testsuite/25_algorithms/lexicographical_compare/uchar.cc: New test.
We were enabling the memcmp optimization in ranges::lexicographical_compare for
signed integral types and for integral types wider than a byte. But memcmp
gives the wrong answer for arrays of such types. This patch fixes this issue by
refining the condition that enables the memcmp optimization. It's now
consistent with the corresponding condition used in
std::lexicographical_compare.
libstdc++-v3/ChangeLog:
PR libstdc++/93972
* include/bits/ranges_algo.h (__lexicographical_compare_fn::operator()):
Fix condition for when to use memcmp, making it consistent with the
corresponding condition used in std::lexicographical_compare.
* testsuite/25_algorithms/lexicographical_compare/93972.cc: New test.
Tested with
make check RUNTESTFLAGS="conformance.exp=*numeric*synopsis* --target_board=unix/-std=$std"
for std in {c++98, c++11, c++17, c++2a}.
libstdc++-v3/ChangeLog:
* testsuite/26_numerics/headers/numeric/synopsis.cc: Add signatures for
functions introduced in C++11, C++17 and C++2a. Add 'constexpr' to
existing signatures for C++2a.
And it only needs to define _GLIBCXX_ASSERTIONS not _GLIBCXX_DEBUG.
* testsuite/24_iterators/range_operations/advance_debug_neg.cc: Run
test instead of just compiling it.
This patch adds memoization to these four views so that their begin() has the
required amortized constant time complexity.
The cache is enabled only for forward_ranges and above because we need the
underlying iterator to be copyable and multi-pass in order for the cache to be
usable. In the general case we represent the cached result of begin() as a bare
iterator. This takes advantage of the fact that value-initialized forward
iterators can be compared to as per N3644, so we can use a value-initialized
iterator to denote the "empty" state of the cache.
As a special case, when the underlying range models random_access_range and when
it's profitable size-wise, then we cache the offset of the iterator from the
beginning of the range instead of caching the iterator itself.
Additionally, in drop_view and reverse_view we disable the cache when the
underlying range models random_access_range, because in these cases recomputing
begin() takes O(1) time anyway.
libstdc++-v3/ChangeLog:
* include/std/ranges (__detail::_CachedPosition): New struct.
(views::filter_view::_S_needs_cached_begin): New member variable.
(views::filter_view::_M_cached_begin): New member variable.
(views::filter_view::begin): Use _M_cached_begin to cache its
result.
(views::drop_view::_S_needs_cached_begin): New static member variable.
(views::drop_view::_M_cached_begin): New member variable.
(views::drop_view::begin): Use _M_cached_begin to cache its result
when _S_needs_cached_begin.
(views::drop_while_view::_M_cached_begin): New member variable.
(views::drop_while_view::begin): Use _M_cached_begin to cache its
result.
(views::reverse_view::_S_needs_cached_begin): New static member
variable.
(views::reverse_view::_M_cached_begin): New member variable.
(views::reverse_view::begin): Use _M_cached_begin to cache its result
when _S_needs_cached_begin.
* testsuite/std/ranges/adaptors/drop.cc: Augment test to check that
drop_view::begin caches its result.
* testsuite/std/ranges/adaptors/drop_while.cc: Augment test to check
that drop_while_view::begin caches its result.
* testsuite/std/ranges/adaptors/filter.cc: Augment test to check that
filter_view::begin caches its result.
* testsuite/std/ranges/adaptors/reverse.cc: Augment test to check that
reverse_view::begin caches its result.
These tests were failing on XFS because it doesn't support setting file
timestamps past 2038, so the expected overflow when reading back a huge
timestamp into a file_time_type didn't happen.
Additionally, the std::filesystem::file_time_type::clock has an
epoch that is out of range of 32-bit time_t so testing times around that
epoch may also fail.
This fixes the tests to give up gracefully if the filesystem doesn't
support times that can't be represented in 32-bit time_t.
* testsuite/27_io/filesystem/operations/last_write_time.cc: Fixes for
filesystems that silently truncate timestamps.
* testsuite/experimental/filesystem/operations/last_write_time.cc:
Likewise.
This fixes a failure due to a (correct) warning seen when testing with
-D_GLIBCXX_USE_CXX11_ABI=0 -D_GLIBCXX_ASSERTIONS:
include/bits/char_traits.h:365: warning: 'void* __builtin_memcpy(void*, const void*, long unsigned int)'
specified bound 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=]
FAIL: 21_strings/basic_string/cons/char/1.cc (test for excess errors)
* testsuite/21_strings/basic_string/cons/char/1.cc: Disable
-Wstringop-overflow warnings.
Some of the range adaptors have distinct constant and non-constant
iterator/sentinel types, along with converting constructors that can convert a
non-constant iterator/sentinel to a constant iterator/sentinel. This patch adds
the missing appropriate friend declarations in order to make these converting
constructors well formed.
Strictly speaking it seems the friendship relations don't need to go both ways
-- we could get away with declaring e.g. friend _Iterator<false>; instead of
friend _Iterator<!_Const>; but both reference implementations seem to use the
latter symmetric form anyway.
libstdc++-v3/ChangeLog:
* include/std/ranges (transform_view::_Iterator<_Const>): Befriend
_Iterator<!_Const>.
(transform_view::_Sentinel<_Const>): Befriend _Sentinel<!_Const>.
(take_view::_Sentinel<_Const>): Likewise.
(take_while_view::_Sentinel<_Const>): Likewise.
(split_view::_OuterIter<_Const>): Befriend _OuterIter<!_Const>.
* testsuite/std/ranges/adaptors/split.cc: Augment test.
* testsuite/std/ranges/adaptors/take.cc: Augment test.
* testsuite/std/ranges/adaptors/take_while.cc: Augment test.
* testsuite/std/ranges/adaptors/transform.cc: Augment test.
This fixes the failures in the constrained algos tests when they are run in
debug mode.
libstdc++-v3/ChangeLog:
* testsuite/25_algorithms/copy/constrained.cc: Don't assume that the
base() of a vector<>::iterator is a pointer.
* testsuite/25_algorithms/copy_backward/constrained.cc: Likewise.
* testsuite/25_algorithms/move/constrained.cc: Likewise.
* testsuite/25_algorithms/move_backward/constrained.cc: Likewise.
* testsuite/25_algorithms/inplace_merge/constrained.cc: Use foo.data()
instead of &foo[0].
* testsuite/25_algorithms/partial_sort/constrained.cc: Likewise.
* testsuite/25_algorithms/partial_sort_copy/constrained.cc: Likewise.
* testsuite/25_algorithms/shuffle/constrained.cc: Likewise.
* testsuite/25_algorithms/sort/constrained.cc: Likewise.
* testsuite/25_algorithms/stable_sort/constrained.cc: Likewise.
This fixes a test failure with -D_GLIBCXX_DEBUG:
FAIL: 23_containers/array/comparison_operators/constexpr.cc (test for excess errors)
* include/debug/array (operator<=>): Define for C++20.
* testsuite/23_containers/array/tuple_interface/get_debug_neg.cc:
Adjust dg-error line numbers.
* testsuite/23_containers/array/tuple_interface/
tuple_element_debug_neg.cc: Likewise.
Comparing value-initialized forward_iterator_wrapper<T> objects fails an
assertion, but should be valid in C++14 and later.
* testsuite/util/testsuite_iterators.h (forward_iterator_wrapper): Add
equality comparisons that support value-initialized iterators.
Although most of the old-style "concept checks" are only really usable
with C++98 because they enforce the wrong things, this is a simple
change that makes them a bit more useful for C++14 and up.
* include/bits/boost_concept_check.h (__function_requires): Add
_GLIBCXX14_CONSTEXPR.
* testsuite/25_algorithms/min/concept_checks.cc: New test.
We are calling _OuterIter::__current from _InnerIter::operator==, but the former
is private within this non-member friend. Fix this by calling
_OuterIter::operator== instead, which does the right thing here.
libstdc++-v3/ChangeLog:
PR libstdc++/93936
* include/std/ranges (split_view::_InnerIter::operator==): Compare
the operands' _M_i rather than their _M_i.current().
* testsuite/std/ranges/adaptors/split.cc: Augment test.
libstdc++-v3/ChangeLog:
LWG 3325 Constrain return type of transformation function for
transform_view
* include/std/ranges (transform_view): Constrain the return type of the
transformation function as per LWG 3325.
* testsuite/std/ranges/adaptors/lwg3325_neg.cc: New test.
libstdc++-v3/ChangeLog:
LWG 3292 iota_view is under-constrained
* include/std/ranges (iota_view): Require that _Winc models semiregular
as per LWG 3292.
* testsuite/std/ranges/iota/lwg3292_neg.cc: New test.
The mutating sequence algorithms std::copy, std::copy_backward,
std::move and std::move_backward conditionally use __builtin_memmove
for trivially copyable types. However, because memmove isn't usable in
constant expressions the use of __builtin_memmove is wrapped in a
__memmove function which replaces __builtin_memmove with a handwritten
loop when std::is_constant_evaluated() is true.
This means we have a manual loop for non-trivially copyable cases, and a
different manual loop for trivially copyable but constexpr cases. The
latter loop has incorrect semantics for the {copy,move}_backward cases
and so isn't used for them. Until earlier today the latter loop also had
incorrect semantics for the std::move cases, trying to move from const
rvalues.
The approach taken by this patch is to remove the __memmove function
entirely and use the original (and correct) manual loops for the
constexpr cases as well as the non-trivially copyable cases. This was
already done for move_backward and copy_backward, but was incorrectly
turning copy_backward into move_backward, by failing to use the _IsMove
constant to select the right specialization. This patch also fixes that.
* include/bits/ranges_algobase.h (__copy_or_move): Do not use memmove
during constant evaluation. Call __builtin_memmove directly instead of
__memmove.
(__copy_or_move_backward): Likewise.
* include/bits/stl_algobase.h (__memmove): Remove.
(__copy_move<M, true, random_access_iterator_tag>::__copy_m)
(__copy_move_backward<M, true, random_access_iterator_tag>::__copy_m):
Use __builtin_memmove directly instead of __memmove.
(__copy_move_a2): Do not use memmove during constant evaluation.
(__copy_move_backward_a2): Use _IsMove constant to select correct
__copy_move_backward specialization.
* testsuite/25_algorithms/copy_backward/constexpr.cc: Check for copies
begin turned into moves during constant evaluation.
The std::move and std::move_backward algorithms dispatch to the
std::__memmove helper when appropriate. That function uses a
pointer-to-const for the source values, preventing them from being
moved. The two callers of that function have the same problem.
Rather than altering __memmove and its callers to work with const or
non-const source pointers, this takes a more conservative approach of
casting away the const at the point where we want to do a move
assignment. This relies on the fact that we only use __memmove when the
type is trivially copyable, so we know the move assignment doesn't alter
the source anyway.
PR libstdc++/93872
* include/bits/stl_algobase.h (__memmove): Cast away const before
doing move assignment.
* testsuite/25_algorithms/move/93872.cc: New test.
* testsuite/25_algorithms/move_backward/93872.cc: New test.
This adds some missing pieces of the Ranges TS that make back_insert_iterator and
front_insert_iterator conform to the new output_iterator requirements.
It also fixes a bug in ranges::__copy_or_move and
ranges::__copy_or_move_backward in which we were inspecting the iter_value_t of
the output iterator, but output iterators such as back_insert_iterator and
front_insert_iterator whose value_type = void do not have an iter_value_t
according to [readable.traits] p4. The entire __use_memmove condition should
probably be rewritten, but the simplest fix for now is to inspect the
iterator_traits of the output iterator instead.
libstdc++-v3/ChangeLog:
PR libstdc++/93884
* include/bits/ranges_algobase.h (__copy_or_move,
__copy_or_move_backward): Don't inspect the iter_value_t of the output
iterator, instead inspect its iterator_traits directly.
* include/bits/stl_iterator.h (back_insert_iterator::container):
Conditionally initialize.
(back_insert_iterator::difference_type): Conditionally define.
(back_insert_iterator::back_insert_iterator): Conditionally define this
default constructor.
(front_insert_iterator::container): Conditionally initialize.
(front_insert_iterator::difference_type): Conditionally define.
(front_insert_iterator::front_insert_iterator): Conditionally define
this default constructor.
* 24_iterators/back_insert_iterator/pr93884.cc: New test.
* 24_iterators/front_insert_iterator/pr93884.cc: New test.
This patch adds std::shift_left and std::shift_right as per P0769R2. Alhough
these are STL-style algos, this patch places them in <bits/ranges_algo.h>
because they make use of some functions in the ranges namespace that are more
easily reachable from <bits/ranges_algo.h> than from <bits/stl_algo.h>, namely
ranges::next. In order to place these algos in <bits/stl_algo.h>, we would need
to include <bits/range_access.h> from <bits/stl_algo.h> which would undesirably
increase the size of <bits/stl_algo.h>.
libstdc++-v3/ChangeLog:
P0769R2 Add shift to <algorithm>
* include/bits/ranges_algo.h (shift_left, shift_right): New.
* testsuite/25_algorithms/shift_left/1.cc: New test.
* testsuite/25_algorithms/shift_right/1.cc: New test.
Somehow I missed that the _M_value member can throw on construction.
* include/bits/stream_iterator.h (istream_iterator(default_sentinel_t)):
Make noexcept-specifier conditional.
* testsuite/24_iterators/istream_iterator/cons/sentinel.cc: Check
noexcept-specifier.
Missing pieces of P0896R4 "The One Ranges Proposal" for C++20.
* include/bits/stream_iterator.h (istream_iterator(default_sentinel_t)):
Add constructor.
(operator==(istream_iterator, default_sentinel_t)): Add operator.
(ostream_iterator::difference_type): Define to ptrdiff_t for C++20.
* include/bits/streambuf_iterator.h
(istreambuf_iterator(default_sentinel_t)): Add constructor.
(operator==(istreambuf_iterator, default_sentinel_t)): Add operator.
* testsuite/24_iterators/istream_iterator/cons/sentinel.cc:
New test.
* testsuite/24_iterators/istream_iterator/sentinel.cc: New test.
* testsuite/24_iterators/istreambuf_iterator/cons/sentinel.cc:
New test.
* testsuite/24_iterators/istreambuf_iterator/sentinel.cc: New test.
