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.
These direct uses of _M_current should all be __current() so they are
valid when the base type doesn't satisfy the forward_range concept.
* include/std/ranges (split_view::_OuterIter::__at_end): Use __current
instead of _M_current.
(split_view::_OuterIter::operator++): Likewise.
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.
G++ fails to diagnose this non-dependent expression, but Clang doesn't
like it.
PR c++/94117
* include/std/ranges (ranges::transform_view::_Iterator::iter_move):
Change expression in noexcept-specifier to match function body.
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.
zTPF uses the same numeric value for ENOSYS and ENOTSUP.
libstdc++-v3/ChangeLog:
2020-03-06 Andreas Krebbel <krebbel@linux.ibm.com>
* src/c++11/system_error.cc: Omit the ENOTSUP case statement if it
would match ENOSYS.
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.
The discussion of iterator_traits<volatile T*>::value_type and the
example with three tempalte arguments related to an earlier version of
the patch, not the one committed.
Also improve the comment on __memcmpable.
* include/bits/cpp_type_traits.h (__memcpyable): Fix comment.
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.
We are passing a value type as the first argument to is_nothrow_assignable_v,
but the result of that is inevitably false. Since this predicate is a part of
the condition that guards the corresponding optimizations for these algorithms,
this bug means these optimizations are never used. We should be passing a
reference type to is_nothrow_assignable_v instead.
libstdc++-v3/ChangeLog:
* include/bits/ranges_uninitialized.h
(uninitialized_copy_fn::operator()): Pass a reference type as the first
argument to is_nothrow_assignable_v.
(uninitialized_copy_fn::operator()): Likewise.
(uninitialized_move_fn::operator()): Likewise. Return an in_out_result
with the input iterator stripped of its move_iterator.
(uninitialized_move_n_fn::operator()): Likewise.
(uninitialized_fill_fn::operator()): Pass a reference type as the first
argument to is_nothrow_assignable_v.
(uninitialized_fill_n_fn::operator()): 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.
As noted in LWG 3410 the specification in the C++20 draft performs more
iterator comparisons than necessary when the end of either range is
reached. Our implementation followed that specification. This removes
the redundant comparisons so that we do no unnecessary work as soon as
we find that we've reached the end of either range.
The odd-looking return statement is because it generates better code
than the original version that copied the global constants.
* include/bits/stl_algobase.h (lexicographical_compare_three_way):
Avoid redundant iterator comparisons (LWG 3410).
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.
The key property of this alias is not that it may be an empty type, but
that the type argument may not be used. The fact it's replaced by an
empty type is just an implementation detail. The name was also
backwards with respect to the bool argument.
This patch changes the name to better reflect its purpose.
* include/std/ranges (__detail::__maybe_empty_t): Rename to
__maybe_present_t.
(__adaptor::_RangeAdaptor, join_view, split_view): Use new name.
Move std::is_permutation algorithm with associated helpers to stl_algobase.h
to remove stl_algo.h include from hashtable_policy.h and so reduce preprocess
size of unordered_map and unordered_set headers.
* include/bits/stl_algo.h
(__find_if, __count_if, __is_permutation, std::is_permutation): Move...
* include/bits/stl_algobase.h: ...here.
* include/bits/hashtable_policy.h: Remove <bits/stl_algo.h> include.
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.
When the underlying range models common_range, then reverse_view::begin() is
already O(1) without caching. So we should disable the cache in this case too.
libstdc++-v3/ChangeLog:
* include/std/ranges (reverse_view::_S_needs_cached_begin): Set to false
whenever the underlying range models common_range.
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.
This fixes a test failure with -std=gnu++98 -D_GLIBCXX_DEBUG:
FAIL: 21_strings/basic_string/modifiers/insert/char/1.cc (test for excess errors)
* include/debug/string (__gnu_debug::basic_string::insert): Fix for
C++98 where the member function of the base class returns void.
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.
