I caused a regression with commit r10-908 by adding a constraint to the
non-explicit allocator-extended default constructor, but seemingly
forgot to add an explicit overload with the corresponding constraint.
libstdc++-v3/ChangeLog:
PR libstdc++/114147
* include/std/tuple (tuple::tuple(allocator_arg_t, const Alloc&)):
Add missing overload of allocator-extended default constructor.
(tuple<T1,T2>::tuple(allocator_arg_t, const Alloc&)): Likewise.
* testsuite/20_util/tuple/cons/114147.cc: New test.
This implements the C++23 paper P2165R4 Compatibility between tuple,
pair and tuple-like objects, which builds upon many changes from the
earlier C++23 paper P2321R2 zip.
Some declarations had to be moved around so that they're visible from
<bits/stl_pair.h> without introducing new includes and bloating the
header. In the end, the only new include is for <bits/utility.h> from
<bits/stl_iterator.h>, for tuple_element_t.
PR libstdc++/113309
PR libstdc++/109203
libstdc++-v3/ChangeLog:
* include/bits/ranges_util.h (__detail::__pair_like): Don't
define in C++23 mode.
(__detail::__pair_like_convertible_from): Adjust as per P2165R4.
(__detail::__is_subrange<subrange>): Moved from <ranges>.
(__detail::__is_tuple_like_v<subrange>): Likewise.
* include/bits/stl_iterator.h: Include <bits/utility.h> for
C++23.
(__different_from): Move to <concepts>.
(__iter_key_t): Adjust for C++23 as per P2165R4.
(__iter_val_t): Likewise.
* include/bits/stl_pair.h (pair, array): Forward declare.
(get): Forward declare all overloads relevant to P2165R4
tuple-like constructors.
(__is_tuple_v): Define for C++23.
(__is_tuple_like_v): Define for C++23.
(__tuple_like): Define for C++23 as per P2165R4.
(__pair_like): Define for C++23 as per P2165R4.
(__eligibile_tuple_like): Define for C++23.
(__eligibile_pair_like): Define for C++23.
(pair::_S_constructible_from_pair_like): Define for C++23.
(pair::_S_convertible_from_pair_like): Define for C++23.
(pair::_S_dangles_from_pair_like): Define for C++23.
(pair::pair): Define overloads taking a tuple-like type for
C++23 as per P2165R4.
(pair::_S_assignable_from_tuple_like): Define for C++23.
(pair::_S_const_assignable_from_tuple_like): Define for C++23.
(pair::operator=): Define overloads taking a tuple-like type for
C++23 as per P2165R4.
* include/bits/utility.h (ranges::__detail::__is_subrange):
Moved from <ranges>.
* include/bits/version.def (tuple_like): Define for C++23.
* include/bits/version.h: Regenerate.
* include/std/concepts (__different_from): Moved from
<bits/stl_iterator.h>.
(ranges::__swap::__adl_swap): Clarify which __detail namespace.
* include/std/map (__cpp_lib_tuple_like): Define C++23.
* include/std/ranges (__detail::__is_subrange): Moved to
<bits/utility.h>.
(__detail::__is_subrange<subrange>): Moved to <bits/ranges_util.h>
(__detail::__has_tuple_element): Adjust for C++23 as per P2165R4.
(__detail::__tuple_or_pair): Remove as per P2165R4. Replace all
uses with plain tuple as per P2165R4.
* include/std/tuple (__cpp_lib_tuple_like): Define for C++23.
(__tuple_like_tag_t): Define for C++23.
(__tuple_cmp): Forward declare for C++23.
(_Tuple_impl::_Tuple_impl): Define overloads taking
__tuple_like_tag_t and a tuple-like type for C++23.
(_Tuple_impl::_M_assign): Likewise.
(tuple::__constructible_from_tuple_like): Define for C++23.
(tuple::__convertible_from_tuple_like): Define for C++23.
(tuple::__dangles_from_tuple_like): Define for C++23.
(tuple::tuple): Define overloads taking a tuple-like type for
C++23 as per P2165R4.
(tuple::__assignable_from_tuple_like): Define for C++23.
(tuple::__const_assignable_from_tuple_like): Define for C++23.
(tuple::operator=): Define overloads taking a tuple-like type
for C++23 as per P2165R4.
(tuple::__tuple_like_common_comparison_category): Define for C++23.
(tuple::operator<=>): Define overload taking a tuple-like type
for C++23 as per P2165R4.
(array, get): Forward declarations moved to <bits/stl_pair.h>.
(tuple_cat): Constrain with __tuple_like for C++23 as per P2165R4.
(apply): Likewise.
(make_from_tuple): Likewise.
(__tuple_like_common_reference): Define for C++23.
(basic_common_reference): Adjust as per P2165R4.
(__tuple_like_common_type): Define for C++23.
(common_type): Adjust as per P2165R4.
* include/std/unordered_map (__cpp_lib_tuple_like): Define for
C++23.
* include/std/utility (__cpp_lib_tuple_like): Define for C++23.
* testsuite/std/ranges/zip/1.cc (test01): Adjust to handle pair
and 2-tuple interchangeably.
(test05): New test.
* testsuite/20_util/pair/p2165r4.cc: New test.
* testsuite/20_util/tuple/p2165r4.cc: New test.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
I accidentally used && in a fold-expression instead of || which meant
that in C++17 the tuple(UElements&&...) constructor only failed its
debug assertion if all tuple elements were dangling references. Some
missing tests (noted as "TODO") meant this wasn't tested.
This fixes the fold expression and adds the missing tests.
libstdc++-v3/ChangeLog:
PR libstdc++/108822
* include/std/tuple (__glibcxx_no_dangling_refs) [C++17]: Fix
wrong fold-operator.
* testsuite/20_util/tuple/dangling_ref.cc: Check tuples with one
element and three elements. Check allocator-extended
constructors.
Guard <tuple> additions from P2321R2 zip with __cpp_lib_ranges_zip
instead of __cplusplus > 202020L.
libstdc++-v3/ChangeLog:
* include/std/tuple [__cplusplus > 202002L]: Guard P2321R2
changes with __cpp_lib_ranges_zip instead.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
When using a compiler that doesn't define __cpp_conditional_explicit
there's a redefinition error for tuple::__nothrow_assignable. This is
because it's defined in different places for the pre-C++20 and C++20
implementations, which are controled by different preprocessor
conditions. For certain combinations of C++20 feature test macros it's
possible for both __nothrow_assignable definitions to be in scope.
Move the pre-C++20 __assignable and __nothrow_assignable definitions adjacent to
their use, so that only one set of definitions is visible for any given
set of feature test macros.
libstdc++-v3/ChangeLog:
PR libstdc++/108822
* include/std/tuple (__assignable, __is_nothrow_assignable):
Move pre-C++20 definitions adjacent to their use.
This is the last part of PR libstdc++/108822 implementing P2255R2, which
makes it ill-formed to create a std::tuple that would bind a reference
to a temporary.
The dangling checks are implemented as deleted constructors for C++20
and higher, and as Debug Mode static assertions in the constructor body
for older standards. This is similar to the r13-6084-g916ce577ad109b
changes for std::pair.
As part of this change, I've reimplemented most of std::tuple for C++20,
making use of concepts to replace the enable_if constraints, and using
conditional explicit to avoid duplicating most constructors. We could
use conditional explicit for the C++11 implementation too (with pragmas
to disables the -Wc++17-extensions warnings), but that should be done as
a stage 1 change for GCC 15 rather than now.
The partial specialization for std::tuple<T1, T2> is no longer used for
C++20 (or more precisely, for a C++20 compiler that supports concepts
and conditional explicit). The additional constructors and assignment
operators that take std::pair arguments have been added to the C++20
implementation of the primary template, with sizeof...(_Elements)==2
constraints. This avoids reimplementing all the other constructors in
the std::tuple<T1, T2> partial specialization to use concepts. This way
we avoid four implementations of every constructor and only have three!
(The primary template has an implementation of each constructor for
C++11 and another for C++20, and the tuple<T1,T2> specialization has an
implementation of each for C++11, so that's three for each constructor.)
In order to make the constraints more efficient on the C++20 version of
the default constructor I've also added a variable template for the
__is_implicitly_default_constructible trait, implemented using concepts.
libstdc++-v3/ChangeLog:
PR libstdc++/108822
* include/std/tuple (tuple): Add checks for dangling references.
Reimplement constraints and constant expressions using C++20
features.
* include/std/type_traits [C++20]
(__is_implicitly_default_constructible_v): Define.
(__is_implicitly_default_constructible): Use variable template.
* testsuite/20_util/tuple/dangling_ref.cc: New test.
Reviewed-by: Patrick Palka <ppalka@redhat.com>
This change moves the definitions of feature test macros (or strictly
speaking, the requests for <bits/version.h> to define them) so that only
standard headers define them. For example, <bits/shared_ptr.h> will no
longer define macros related to std::shared_ptr, only <memory> and
<version> will define them. This means that __cpp_lib_shared_ptr_arrays
will not be defined by <future> or by other headers that include
<bits/shared_ptr.h>. It will only be defined when <memory> has been
included. This will discourage users from relying on transitive
includes.
As a result, internal headers that need to query the macros should use
the internal macros like __glibcxx_shared_ptr_arrays instead of
__cpp_lib_shared_ptr_arrays, as those internal macros are defined by the
internal headers after icluding <bits/version.h>. There are some
exceptions to this rule, because __cpp_lib_is_constant_evaluated is
defined by bits/c++config.h and so is available everywhere, and
__cpp_lib_three_way_comparison is defined by <compare> which several
headers are explicitly specified to include, so its macro is guaranteed
to be usable too.
N.B. not many internal headers actually need an explicit include of
<bits/version.h>, because most of them include <type_traits> and so get
all the __glibcxx_foo internal macros from there.
libstdc++-v3/ChangeLog:
* include/bits/algorithmfwd.h: Do not define standard feature
test macro here.
* include/bits/align.h: Likewise. Test internal macros instead
of standard macros.
* include/bits/alloc_traits.h: Likewise.
* include/bits/allocator.h: Likewise.
* include/bits/atomic_base.h: Likewise.
* include/bits/atomic_timed_wait.h: Likewise.
* include/bits/atomic_wait.h: Likewise.
* include/bits/basic_string.h: Likewise.
* include/bits/basic_string.tcc: Likewise.
* include/bits/char_traits.h: Likewise.
* include/bits/chrono.h: Likewise.
* include/bits/cow_string.h: Likewise.
* include/bits/forward_list.h: Likewise.
* include/bits/hashtable.h: Likewise.
* include/bits/ios_base.h: Likewise.
* include/bits/memory_resource.h: Likewise.
* include/bits/move.h: Likewise.
* include/bits/move_only_function.h: Likewise.
* include/bits/node_handle.h: Likewise.
* include/bits/ptr_traits.h: Likewise.
* include/bits/range_access.h: Likewise.
* include/bits/ranges_algo.h: Likewise.
* include/bits/ranges_cmp.h: Likewise.
* include/bits/ranges_util.h: Likewise.
* include/bits/semaphore_base.h: Likewise.
* include/bits/shared_ptr.h: Likewise.
* include/bits/shared_ptr_atomic.h: Likewise.
* include/bits/shared_ptr_base.h: Likewise.
* include/bits/stl_algo.h: Likewise.
* include/bits/stl_algobase.h: Likewise.
* include/bits/stl_function.h: Likewise.
* include/bits/stl_iterator.h: Likewise.
* include/bits/stl_list.h: Likewise.
* include/bits/stl_map.h: Likewise.
* include/bits/stl_pair.h: Likewise.
* include/bits/stl_queue.h: Likewise.
* include/bits/stl_stack.h: Likewise.
* include/bits/stl_tree.h: Likewise.
* include/bits/stl_uninitialized.h: Likewise.
* include/bits/stl_vector.h: Likewise.
* include/bits/unique_ptr.h: Likewise.
* include/bits/unordered_map.h: Likewise.
* include/bits/uses_allocator_args.h: Likewise.
* include/bits/utility.h: Likewise.
* include/bits/erase_if.h: Add comment.
* include/std/algorithm: Define standard feature test macros
here.
* include/std/atomic: Likewise.
* include/std/array: Likewise.
* include/std/chrono: Likewise.
* include/std/condition_variable: Likewise.
* include/std/deque: Likewise.
* include/std/format: Likewise.
* include/std/functional: Likewise.
* include/std/forward_list: Likewise.
* include/std/ios: Likewise.
* include/std/iterator: Likewise.
* include/std/list: Likewise.
* include/std/map: Likewise.
* include/std/memory: Likewise.
* include/std/numeric: Likewise.
* include/std/queue: Likewise.
* include/std/ranges: Likewise.
* include/std/regex: Likewise.
* include/std/set: Likewise.
* include/std/stack: Likewise.
* include/std/stop_token: Likewise.
* include/std/string: Likewise.
* include/std/string_view:
* include/std/tuple: Likewise.
* include/std/unordered_map:
* include/std/unordered_set:
* include/std/utility: Likewise.
* include/std/vector: Likewise.
* include/std/scoped_allocator: Query internal macros instead of
standard macros.
The non-reserved names 'val' and 'dest' were being used in our headers
but haven't been added to the 17_intro/names.cc test. That's because
they are used by <asm-generic/posix_types.h> and <netinet/tcp.h>
respecitvely on glibc-based systems.
libstdc++-v3/ChangeLog:
* include/bits/fs_ops.h (create_directory): Use reserved name
for parameter.
* include/bits/ranges_algo.h (__contains_subrange_fn):
Likewise.
* include/bits/regex_automaton.h (_State_base::_M_print):
Likewise.
* include/bits/regex_automaton.tcc(_State_base::_M_print):
Likewise.
* include/bits/regex_scanner.tcc(_Scanner::_M_print): Likewise.
* include/experimental/bits/fs_ops.h (create_directory):
Likewise.
* include/std/mutex (timed_mutex::_M_clocklock): Likewise.
(recursive_timed_mutex:_M_clocklock): Likewise.
* include/std/tuple (basic_common_reference): Likewise.
* libsupc++/cxxabi_init_exception.h
(__cxa_init_primary_exception): Likewise.
* testsuite/17_intro/names.cc: Add checks.
In order for std::make_from_tuple to work with tuple-like types, the
overloads of std::get for those types must have been declared before the
definition of std::make_from_tuple. That means we need to include the
definition of std::ranges::subrange in <tuple>.
The definitions of std::pair and its overloads of std::get are already
included in <tuple>. We provide forward declarations of std::array and
its std::get overloads in <tuple>. We could just declare subrange
without defining it, and give ranges::get a non-deduced return type,
like so:
namespace ranges
{
enum class subrange_kind : bool { unsized, sized};
template<input_or_output_iterator I, sentinel_for<I> S,
subrange_kind K>
requires (K == subrange_kind::sized || !sized_sentinel_for<S, I>)
class subrange;
template<size_t _Num, class _It, class _Sent, subrange_kind _Kind>
requires (_Num < 2)
constexpr __conditional_t<_Num == 0, _It, _Sent>
get(const subrange<_It, _Sent, _Kind>& __r);
template<size_t _Num, class _It, class _Sent, subrange_kind _Kind>
requires (_Num < 2)
constexpr __conditional_t<_Num == 0, _It, _Sent>
get(subrange<_It, _Sent, _Kind>&& __r)
}
using ranges::get;
It is a bit late in the GCC 13 dev cycle to do this, so just include the
right headers for now.
Also add the dangling check to std::make_from_tuple added by P2255.
libstdc++-v3/ChangeLog:
PR libstdc++/102301
* include/bits/ranges_base.h: Include <bits/stl_iterator.h> for
std::make_reverse_iterator.
* include/std/tuple: Include <bits/ranges_util.h> for subrange.
(make_from_tuple): Add static assertion from P2255 to diagnose
dangling references.
* testsuite/20_util/tuple/make_from_tuple/dangling_ref.cc: New test.
* testsuite/20_util/tuple/make_from_tuple/tuple_like.cc: New test.
Now that these internal type traits are (again) class templates, it's
better to derive from the trait's ::type instead of from the trait
itself, for sake of a shallower inheritance chain.
libstdc++-v3/ChangeLog:
* include/std/tuple (tuple::_UseOtherCtor): Use ::type when
deriving from __and_, __or_ or __not_.
* include/std/type_traits (negation): Likewise.
(is_unsigned): Likewise.
(__is_implicitly_default_constructible): Likewise.
(is_trivially_destructible): Likewise.
(__is_nt_invocable_impl): Likewise.
r13-2159-g72886fcc626953 caused some testsuite regressions in C++23 mode:
FAIL: 20_util/pair/requirements/explicit_instantiation/1.cc (test for excess errors)
FAIL: 20_util/tuple/53648.cc (test for excess errors)
FAIL: 20_util/tuple/cons/noexcept_specs.cc (test for excess errors)
FAIL: 20_util/tuple/requirements/explicit_instantiation.cc (test for excess errors)
The test noexcept_specs.cc just needs to be updated to consider the
additional converting constructors of tuple in C++23 mode, which happen
to improve constructing from a const tuple rvalue that has an rvalue
reference element (for the better, as far as I can tell).
The other three tests fail because they explicitly instantiate a
specialization of pair/tuple whose elements are not all const swappable,
which in C++23 mode now results in a hard error due to the new const
swap member function. Rather than XFAILing the tests in C++23 mode,
this patch adds non-standard constraints to this member function so that
we continue to accept such explicit instantiations.
libstdc++-v3/ChangeLog:
* include/bits/stl_pair.h (pair::swap const): Add non-standard
is_swappable_v constraints.
* include/std/tuple (tuple::swap const): Likewise.
* testsuite/20_util/tuple/cons/noexcept_specs.cc: Correct some
asserts in C++23 mode.
This implements the non-<ranges> changes from P2321R2, which primarily
consist of additional converting constructors, assignment operator and
swap overloads for std::pair and std::tuple.
libstdc++-v3/ChangeLog:
* include/bits/stl_bvector.h (_Bit_reference::operator=): Define
const overload for C++23 as per P2321R2.
* include/bits/stl_pair.h (pair::swap): Likewise.
(pair::pair): Define additional converting constructors for
C++23 as per P2321R2.
(pair::operator=): Define const overloads for C++23 as per
P2321R2.
(swap): Define overload taking const pair& for C++23 as per
P2321R2.
(basic_common_reference): Define partial specialization for
pair for C++23 as per P2321R2.
(common_type): Likewise.
* include/bits/uses_allocator_args.h
(uses_allocator_construction_args): Define additional pair
overloads for C++23 as per P2321R2.
* include/std/tuple (_Tuple_impl::_Tuple_impl): Define
additional converting constructors for C++23 as per P2321R2.
(_Tuple_impl::_M_assign): Define const overloads for C++23
as per P2321R2.
(_Tuple_impl::_M_swap): Likewise.
(tuple::__constructible): Define as a convenient renaming of
_TCC<true>::__constructible.
(tuple::__convertible): As above but for _TCC<true>::__convertible.
(tuple::tuple): Define additional converting constructors for
C++23 as per P2321R2.
(tuple::operator=): Define const overloads for C++23 as per
P2321R2.
(tuple::swap): Likewise.
(basic_common_reference): Define partial specialization for
tuple for C++23 as per P2321R2.
(common_type): Likewise.
* testsuite/20_util/pair/p2321r2.cc: New test.
* testsuite/20_util/tuple/p2321r2.cc: New test.
* testsuite/23_containers/vector/bool/element_access/1.cc: New test.
P2321R2 adds additional conditionally explicit constructors to std::tuple
which we'll concisely implement in a subsequent patch using explicit(bool),
like in our C++20 std::pair implementation. This prerequisite patch
adds member typedefs to _TupleConstraints for testing element-wise
constructibility and convertibility separately; we'll use the first in
the new constructors' constraints, and the second in their explicit
specifier.
In passing, this patch also redefines the existing member predicates
__is_ex/implicitly_constructible in terms of these new members. This
seems to reduce compile time and memory usage by about 10% for large
tuples when using the converting constructors that're constrained by
_Explicit/_ImplicitCtor.
libstdc++-v3/ChangeLog:
* include/std/tuple (_TupleConstraints::__convertible): Define.
(_TupleConstraints::__constructible): Define.
(_TupleConstraints::__is_explicitly_constructible): Redefine this
in terms of __convertible and __constructible.
(_TupleConstraints::__is_implicitly_constructible): Likewise.
The FE bug was fixed, so we don't need this workaround now.
libstdc++-v3/ChangeLog:
PR libstdc++/96592
* include/std/tuple (tuple::is_constructible): Remove.
Currently std::variant uses __index_of<T, Types...> to find the first
occurence of a type in a pack, and __exactly_once<T, Types...> to check
that there is no other occurrence.
We can reuse the __find_uniq_type_in_pack<T, Types...>() function for
both tasks, and remove the recursive templates used to implement
__index_of and __exactly_once.
libstdc++-v3/ChangeLog:
* include/bits/utility.h (__find_uniq_type_in_pack): Move
definition to here, ...
* include/std/tuple (__find_uniq_type_in_pack): ... from here.
* include/std/variant (__detail__variant::__index_of): Remove.
(__detail::__variant::__exactly_once): Define using
__find_uniq_type_in_pack instead of __index_of.
(get<T>, get_if<T>, variant::__index_of): Likewise.
This reduces the number of class template instantiations needed for code
using tuples, by reusing _Nth_type in tuple_element and specializing
tuple_size_v for tuple, pair and array (and const-qualified versions of
them).
Also define the _Nth_type primary template as a complete type (but with
no nested 'type' member). This avoids "invalid use of incomplete type"
errors for out-of-range specializations of tuple_element. Those errors
would probably be confusing and unhelpful for users. We already have
a user-friendly static assert in tuple_element itself.
Also ensure that tuple_size_v is available whenever tuple_size is (as
proposed by LWG 3387). We already do that for tuple_element_t.
libstdc++-v3/ChangeLog:
* include/bits/stl_pair.h (tuple_size_v): Define partial
specializations for std::pair.
* include/bits/utility.h (_Nth_type): Move definition here
and define primary template.
(tuple_size_v): Move definition here.
* include/std/array (tuple_size_v): Define partial
specializations for std::array.
* include/std/tuple (tuple_size_v): Move primary template to
<bits/utility.h>. Define partial specializations for
std::tuple.
(tuple_element): Change definition to use _Nth_type.
* include/std/variant (_Nth_type): Move to <bits/utility.h>.
(variant_alternative, variant): Adjust qualification of
_Nth_type.
* testsuite/20_util/tuple/element_access/get_neg.cc: Prune
additional errors from _Nth_type.
The r12-3022 commit only fixed the case where an array is the last
element of the tuple. This fixes the other cases too. We can just define
the move constructor as defaulted, which does the right thing. Changing
the move constructor to be trivial would be an ABI break, but since the
last base class still has a non-trivial move constructor, defining the
derived ones as defaulted doesn't change anything.
libstdc++-v3/ChangeLog:
PR libstdc++/101960
* include/std/tuple (_Tuple_impl(_Tuple_impl&&)): Define as
defauled.
* testsuite/20_util/tuple/cons/101960.cc: Check tuples with
array elements before the last element.
This change is inspired by the suggestion in
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1715r0.html
The new std::__conditional_t alias template is functionally equivalent
to std::conditional_t but should be more efficient to compile, due to
only ever instantiating two specializations (std::__conditional<true>
and std::__conditional<false>) rather than a new specialization for
every use of std::conditional.
The new alias template is also available in C++11, unlike the C++14
std::conditional_t alias.
Signed-off-by: Jonathan Wakely <jwakely@redhat.com>
libstdc++-v3/ChangeLog:
* include/std/type_traits (__conditional): New class template
for internal uses of std::conditional.
(__conditional_t): New alias template to replace conditional_t.
(__and_, __or_, __result_of_memfun, __result_of_memobj): Use
__conditional_t instead of conditional::type.
* include/bits/atomic_base.h (__atomic_impl::_Diff): Likewise.
* include/bits/hashtable.h (_Hashtable): Likewise.
* include/bits/hashtable_policy.h (_Node_iterator, _Insert_base)
(_Local_iterator): Likewise. Replace typedefs with
using-declarations.
* include/bits/move.h (move_if_noexcept): Use __conditional_t.
* include/bits/parse_numbers.h (_Select_int_base): Likewise.
* include/bits/ptr_traits.h (__make_not_void): Likewise.
* include/bits/ranges_algobase.h (__copy_or_move_backward)
(__copy_or_move): Likewise.
* include/bits/ranges_base.h (borrowed_iterator_t): Likewise.
* include/bits/ranges_util.h (borrowed_subrange_t): Likewise.
* include/bits/regex_compiler.h (_BracketMatcher): Use
__conditional_t. Replace typedefs with using-declarations.
* include/bits/shared_ptr_base.h (__shared_count): Use
__conditional_t.
* include/bits/stl_algobase.h (__copy_move, __copy_move_backward):
Likewise.
* include/bits/stl_iterator.h (__detail::__clamp_iter_cat)
(reverse_iterator::iterator_concept)
(__make_move_if_noexcept_iterator)
(iterator_traits<common_iterator<_It, _Sent>>)
(iterator_traits<counted_iterator<_It>>): Likewise.
* include/bits/stl_pair.h (_PCC, pair::operator=): Likewise.
* include/bits/stl_tree.h (_Rb_tree::insert_return_type)
(_Rb_tree::_M_clone_node): Likewise.
* include/bits/unique_ptr.h (unique_ptr(unique_ptr<U,E>&&)):
Likewise.
* include/bits/uses_allocator.h (__uses_alloc): Likewise.
(__is_uses_allocator_predicate): Likewise.
* include/debug/functions.h (__foreign_iterator_aux2): Likewise.
* include/experimental/any (any::_Manager, __any_caster):
Likewise.
* include/experimental/executor (async_completion): Likewise.
* include/experimental/functional (__boyer_moore_base_t):
Likewise.
* include/std/any (any::_Manager): Likewise.
* include/std/functional (__boyer_moore_base_t): Likewise.
* include/std/ranges (borrowed_iterator_t)
(borrowed_subrange_t, __detail::__maybe_present_t)
(__detail::__maybe_const_t, split_view): Likewise.
* include/std/tuple (__empty_not_final, tuple::operator=):
Likewise.
* include/std/variant (__detail::__variant::__get_t): Likewise.
Also rename the test so it actually runs.
Signed-off-by: Jonathan Wakely <jwakely@redhat.com>
libstdc++-v3/ChangeLog:
PR libstdc++/102270
* include/std/tuple (_Tuple_impl): Add constexpr to constructor
missed in previous patch.
* testsuite/20_util/tuple/cons/102270.C: Moved to...
* testsuite/20_util/tuple/cons/102270.cc: ...here.
* testsuite/util/testsuite_allocator.h (SimpleAllocator): Add
constexpr to constructor so it can be used for C++20 tests.
An array member cannot be direct-initialized in a ctor-initializer-list,
so use the base class' move constructor, which does the right thing for
both arrays and non-arrays.
This constructor could be defaulted, but that would make it trivial for
some specializations, which would change the argument passing ABI. Do
that for the versioned namespace only.
Signed-off-by: Jonathan Wakely <jwakely@redhat.com>
libstdc++-v3/ChangeLog:
PR libstdc++/101960
* include/std/tuple (_Tuple_impl(_Tuple_impl&&)): Use base
class' move constructor. Define as defaulted for versioned
namespace.
* testsuite/20_util/tuple/cons/101960.cc: New test.
This refactoring reduces the memory usage and compilation time to parse
a number of headers that depend on std::pair, std::tuple or std::array.
Previously the headers for these class templates were all intertwined,
due to the common dependency on std::tuple_size, std::tuple_element and
their std::get overloads. This decouples the headers by moving some
parts of <utility> into a new <bits/utility.h> header. This means that
<array> and <tuple> no longer need to include the whole of <utility>,
and <tuple> no longer needs to include <array>.
This decoupling benefits headers such as <thread> and <scoped_allocator>
which only need std::tuple, and so no longer have to parse std::array.
Some other headers such as <any>, <optional> and <variant> no longer
need to include <utility> just for the std::in_place tag types, so
do not have to parse the std::pair definitions.
Removing direct uses of <utility> also means that the std::rel_ops
namespace is not transitively declared by other headers.
Signed-off-by: Jonathan Wakely <jwakely@redhat.com>
libstdc++-v3/ChangeLog:
* include/Makefile.am: Add bits/utility.h header.
* include/Makefile.in: Regenerate.
* include/bits/utility.h: New file.
* include/std/utility (tuple_size, tuple_element): Move
to new header.
* include/std/type_traits (__is_tuple_like_impl<tuple<T...>>):
Move to <tuple>.
(_Index_tuple, _Build_index_tuple, integer_sequence): Likewise.
(in_place_t, in_place_index_t, in_place_type_t): Likewise.
* include/bits/ranges_util.h: Include new header instead of
<utility>.
* include/bits/stl_pair.h (tuple_size, tuple_element): Move
partial specializations for std::pair here.
(get): Move overloads for std::pair here.
* include/std/any: Include new header instead of <utility>.
* include/std/array: Likewise.
* include/std/memory_resource: Likewise.
* include/std/optional: Likewise.
* include/std/variant: Likewise.
* include/std/tuple: Likewise.
(__is_tuple_like_impl<tuple<T...>>): Move here.
(get) Declare overloads for std::array.
* include/std/version (__cpp_lib_tuples_by_type): Change type
to long.
* testsuite/20_util/optional/84601.cc: Include <utility>.
* testsuite/20_util/specialized_algorithms/uninitialized_fill/constrained.cc:
Likewise.
* testsuite/23_containers/array/tuple_interface/get_neg.cc:
Adjust dg-error line numbers.
* testsuite/std/ranges/access/cbegin.cc: Include <utility>.
* testsuite/std/ranges/access/cend.cc: Likewise.
* testsuite/std/ranges/access/end.cc: Likewise.
* testsuite/std/ranges/single_view.cc: Likewise.
This adds a deleted overload of std::get<I>(const tuple<Types...>&).
Invalid calls with an out of range index will match the deleted overload
and give a single, clear error about calling a deleted function, instead
of overload resolution errors for every std::get overload in the
library.
This changes the current output of 15+ errors (plus notes and associated
header context) into just two errors (plus context):
error: static assertion failed: tuple index must be in range
error: use of deleted function 'constexpr std::__enable_if_t<(__i >= sizeof... (_Types))> std::get(const std::tuple<_Types ...>&) [with long unsigned int __i = 1; _Elements = {int}; std::__enable_if_t<(__i >= sizeof... (_Types))> = void]'
This seems like a nice improvement, although PR c++/66968 means that
"_Types" is printed in the signature rather than "_Elements".
Signed-off-by: Jonathan Wakely <jwakely@redhat.com>
libstdc++-v3/ChangeLog:
* include/std/tuple (get<I>): Add deleted overload for bad
index.
* testsuite/20_util/tuple/element_access/get_neg.cc: Adjust
expected errors.
The std::get<T> functions relied on deduction failing if more than one
base class existed for the type T. However the implementation of Core
DR 2303 (in r11-4693) made deduction succeed (and select the
more-derived base class).
This rewrites the implementation of std::get<T> to explicitly check for
more than one occurrence of T in the tuple elements, making it
ill-formed again. Additionally, the large wall of overload resolution
errors described in PR c++/101460 is avoided by making std::get<T> use
__get_helper<I> directly instead of calling std::get<I>, and by adding a
deleted overload of __get_helper<N> for out-of-range N.
Signed-off-by: Jonathan Wakely <jwakely@redhat.com>
libstdc++-v3/ChangeLog:
PR libstdc++/101427
* include/std/tuple (tuple_element): Improve static_assert text.
(__get_helper): Add deleted overload.
(get<i>(tuple<T...>&&), get<i>(const tuple<T...>&&)): Use
__get_helper directly.
(__get_helper2): Remove.
(__find_uniq_type_in_pack): New constexpr helper function.
(get<T>): Use __find_uniq_type_in_pack and __get_helper instead
of __get_helper2.
* testsuite/20_util/tuple/element_access/get_neg.cc: Adjust
expected errors.
* testsuite/20_util/tuple/element_access/101427.cc: New test.
The no_unique_address attribute is not a reserved name until C++20, so
to use it in C++11/14/17 modes we should use the __no_unique_address_
form. We already use that form when using the attribute, but not in the
__has_cpp_attribute check.
libstdc++-v3/ChangeLog:
PR libstdc++/101055
* include/std/tuple: Use reserved form of attribute name.
* testsuite/17_intro/headers/c++2011/all_attributes.cc: Add
check for no_unique_address.
* testsuite/17_intro/headers/c++2014/all_attributes.cc:
Likewise.
* testsuite/17_intro/headers/c++2017/all_attributes.cc:
Likewise.
Although the compiler supports the [[no_unique_address]] attribute, it's
not a reserved name prior to C++20, so we can't use it in std::tuple.
Use [[__no_unique_address__]] instead.
libstdc++-v3/ChangeLog:
* include/std/tuple (_Head_base<Idx, Head, true>): Use reserved
form of __no_unique_address__ attribute because
no_unique_address is not reserved prior to C++20.
While backporting 5494edae83 I noticed
that it's still not correct. I made the allocator-extended constructor
use the right type for the uses-allocator construction detection, but I
used an rvalue when it should be a const lvalue.
This should fix it properly this time.
libstdc++-v3/ChangeLog:
PR libstdc++/96803
* include/std/tuple
(_Tuple_impl(allocator_arg_t, Alloc, const _Tuple_impl<U...>&)):
Use correct value category in __use_alloc call.
* testsuite/20_util/tuple/cons/96803.cc: Check with constructors
that require correct value category to be used.
This "fix" makes no sense, but it avoids an error from G++ about
std::is_constructible being incomplete. The real problem is elsewhere,
but this "fixes" the regression for now.
libstdc++-v3/ChangeLog:
PR libstdc++/96592
* include/std/tuple (_TupleConstraints<true, T...>): Use
alternative is_constructible instead of std::is_constructible.
* testsuite/20_util/tuple/cons/96592.cc: New test.
The _Tuple_impl constructor for allocator-extended construction from a
different tuple type uses the _Tuple_impl's own _Head type in the
__use_alloc test. That is incorrect, because the argument tuple could
have a different type. Using the wrong type might select the
leading-allocator convention when it should use the trailing-allocator
convention, or vice versa.
libstdc++-v3/ChangeLog:
PR libstdc++/96803
* include/std/tuple
(_Tuple_impl(allocator_arg_t, Alloc, const _Tuple_impl<U...>&)):
Replace parameter pack with a type parameter and a pack and pass
the first type to __use_alloc.
* testsuite/20_util/tuple/cons/96803.cc: New test.
This fixes a number of std::tuple bugs by no longer making use of the
empty base-class optimization. By using the C++20 [[no_unique_address]]
attribute we can always store the element as a data member, while still
compressing the layout of tuples containing empty types.
Since we no longer use inheritance we could also apply the compression
optimization for final types and for tuples of tuples, but doing so
would be an ABI break.
Using [[no_unique_address]] more liberally for the unstable std::__8
configuration is left for a later date. There may be reasons not to
apply the attribute unconditionally, e.g. see the discussion about
guaranteed elision in PR 94062.
libstdc++-v3/ChangeLog:
PR libstdc++/55713
PR libstdc++/71096
PR libstdc++/93147
* include/std/tuple [__has_cpp_attribute(no_unique_address)]
(_Head_base<Idx, Head, true>): New definition of the partial
specialization, using [[no_unique_address]] instead of
inheritance.
* testsuite/libstdc++-prettyprinters/48362.cc: Adjust expected
output.
* testsuite/20_util/tuple/comparison_operators/93147.cc: New test.
* testsuite/20_util/tuple/creation_functions/55713.cc: New test.
* testsuite/20_util/tuple/element_access/71096.cc: New test.
When unpacking a std::tuple we know that the std::get calls are
noexcept, so only the invocation (for std::apply) and construction (for
std::make_from_tuple) can throw.
We also know the std::get calls won't throw for a std::array, but this
patch doesn't specialize the variable template for std::array. For an
arbitrary tuple-like type we don't know if the std::get calls will
throw, and so just use a potentially-throwing noexcept-specifier.
* include/std/tuple (__unpack_std_tuple): New variable template and
partial specializations.
(apply, make_from_tuple): Add noexcept-specifier.
* testsuite/20_util/tuple/apply/2.cc: New test.
* testsuite/20_util/tuple/make_from_tuple/2.cc: New test.
From-SVN: r274312
Replace the _TC class template with the better-named _TupleConstraints
one, which provides a different set of member functions. The new members
do not distinguish construction from lvalues and rvalues, but expects
the caller to do that by providing different template arguments. Within
the std::tuple primary template and std::tuple<T1, T2> partial
specialization the _TupleConstraints members are used via new alias
templates like _ImplicitCtor and _ExplicitCtor which makes the
constructor constraints less verbose and repetitive. For example, where
we previously had:
template<typename... _UElements, typename
enable_if<
_TMC<_UElements...>::template
_MoveConstructibleTuple<_UElements...>()
&& _TMC<_UElements...>::template
_ImplicitlyMoveConvertibleTuple<_UElements...>()
&& (sizeof...(_Elements) >= 1),
bool>::type=true>
constexpr tuple(_UElements&&... __elements)
We now have:
template<typename... _UElements,
bool _Valid = __valid_args<_UElements...>(),
_ImplicitCtor<_Valid, _UElements...> = true>
constexpr
tuple(_UElements&&... __elements)
There are two semantic changes as a result of the refactoring:
- The allocator-extended default constructor is now constrained.
- The rewritten constraints fix PR 90700.
* include/std/tuple (_TC): Replace with _TupleConstraints.
(_TupleConstraints): New helper for SFINAE constraints, with more
expressive member functions to reduce duplication when used.
(tuple::_TC2, tuple::_TMC, tuple::_TNTC): Remove.
(tuple::_TCC): Replace dummy type parameter with bool non-type
parameter that can be used to check the pack size.
(tuple::_ImplicitDefaultCtor, tuple::_ExplicitDefaultCtor)
(tuple::_ImplicitCtor, tuple::_ExplicitCtor): New alias templates for
checking constraints in constructors.
(tuple::__valid_args, tuple::_UseOtherCtor, tuple::__use_other_ctor):
New SFINAE helpers.
(tuple::tuple): Use new helpers to reduce repitition in constraints.
(tuple::tuple(allocator_arg_t, const Alloc&)): Constrain.
(tuple<T1, T2>::_TCC, tuple<T1, T2>::_ImplicitDefaultCtor)
(tuple<T1, T2>::_ExplicitDefaultCtor, tuple<T1, T2>::_ImplicitCtor)
(tuple<T1, T2>::_ExplicitCtor): New alias templates for checking
constraints in constructors.
(tuple::__is_alloc_arg()): New SFINAE helpers.
(tuple<T1, T2>::tuple): Use new helpers to reduce repitition in
constraints.
(tuple<T1, T2>::tuple(allocator_arg_t, const Alloc&)): Constrain.
* testsuite/20_util/tuple/cons/90700.cc: New test.
* testsuite/20_util/tuple/cons/allocators.cc: Add default constructor
to meet new constraint on allocator-extended default constructor.
From-SVN: r271998
