aboutsummaryrefslogtreecommitdiff
path: root/libstdc++-v3/include/std
AgeCommit message (Collapse)AuthorFilesLines
7 dayslibstdc++: Fix std::to_array for trivial-ish types [PR115522]Jonathan Wakely1-2/+6
Due to PR c++/85723 the std::is_trivial trait is true for types with a deleted default constructor, so the use of std::is_trivial in std::to_array is not sufficient to ensure the type can be trivially default constructed then filled using memcpy. I also forgot that a type with a deleted assignment operator can still be trivial, so we also need to check that it's assignable because the is_constant_evaluated() path can't use memcpy. Replace the uses of std::is_trivial with std::is_trivially_copyable (needed for memcpy), std::is_trivially_default_constructible (needed so that the default construction is valid and does no work) and std::is_copy_assignable (needed for the constant evaluation case). libstdc++-v3/ChangeLog: PR libstdc++/115522 * include/std/array (to_array): Workaround the fact that std::is_trivial is not sufficient to check that a type is trivially default constructible and assignable. * testsuite/23_containers/array/creation/115522.cc: New test. (cherry picked from commit 510ce5eed69ee1bea9c2c696fe3b2301e16d1486)
2024-06-04libstdc++: Only define std::span::at for C++26 [PR115335]Jonathan Wakely1-0/+2
In r14-5689-g1fa85dcf656e2f I added std::span::at and made the correct changes to the __cpp_lib_span macro (with tests for the correct value in C++20/23/26). But I didn't make the declaration of std::span::at actually depend on the macro, so it was defined for C++20 and C++23, not only for C++26. This fixes that oversight. libstdc++-v3/ChangeLog: PR libstdc++/115335 * include/std/span (span::at): Guard with feature test macro. (cherry picked from commit 2197814011eec75022aa8550f10621409b69d4a1)
2024-05-28libstdc++: Guard use of sized deallocation [PR114940]Jonathan Wakely1-2/+11
Clang does not enable -fsized-deallocation by default, which means it can't compile our <stacktrace> and <generator> headers. Make the __cpp_lib_generator macro depend on the compiler-defined __cpp_sized_deallocation macro, and change <stacktrace> to use unsized deallocation when __cpp_sized_deallocation isn't defined. libstdc++-v3/ChangeLog: PR libstdc++/114940 * include/bits/version.def (generator): Depend on __cpp_sized_deallocation. * include/bits/version.h: Regenerate. * include/std/stacktrace (_GLIBCXX_SIZED_DELETE): New macro. (basic_stacktrace::_Impl::_M_deallocate): Use it. (cherry picked from commit b2fdd508d7e63158e9d2a6dd04f901d02900def3)
2024-05-22libstdc++: Implement std::formatter<std::thread::id> without <sstream> ↵Jonathan Wakely1-10/+33
[PR115099] The std::thread::id formatter uses std::basic_ostringstream without including <sstream>, which went unnoticed because the test for it uses a stringstream to check the output is correct. The fix implemented here is to stop using basic_ostringstream for formatting thread::id and just use std::format instead. As a drive-by fix, the formatter specialization is constrained to require that the thread::id::native_handle_type can be formatted, to avoid making the formatter ill-formed if the pthread_t type is not a pointer or integer. Since non-void pointers can't be formatted, ensure that we convert pointers to const void* for formatting. Make a similar change to the existing operator<< overload so that in the unlikely case that pthread_t is a typedef for char* we don't treat it as a null-terminated string when inserting into a stream. libstdc++-v3/ChangeLog: PR libstdc++/115099 * include/bits/std_thread.h: Declare formatter as friend of thread::id. * include/std/thread (operator<<): Convert non-void pointers to void pointers for output. (formatter): Add constraint that thread::native_handle_type is a pointer or integer. (formatter::format): Reimplement without basic_ostringstream. * testsuite/30_threads/thread/id/output.cc: Check output compiles before <sstream> has been included. (cherry picked from commit 1a5e4dd83788ea4c049d354d83ad58a6a3d747e6)
2024-05-14libstdc++: Fix typo in std::stacktrace::max_size [PR115063]Jonathan Wakely1-1/+1
libstdc++-v3/ChangeLog: PR libstdc++/115063 * include/std/stacktrace (basic_stacktrace::max_size): Fix typo in reference to _M_alloc member. * testsuite/19_diagnostics/stacktrace/stacktrace.cc: Check max_size() compiles. (cherry picked from commit dd9677f3343ca2a4b4aab9428b8129774accac29)
2024-05-14libstdc++: Guard uses of is_pointer_interconvertible_v [PR114891]Jonathan Wakely1-0/+8
This type trait isn't supported by Clang 18. It's only used in static assertions, so they can just be omitted if the trait isn't available. libstdc++-v3/ChangeLog: PR libstdc++/114891 * include/std/generator: Check feature test macro before using is_pointer_interconvertible_v. (cherry picked from commit 1fbe1a50d86df11f434351cf62461a32747f9710)
2024-04-30libstdc++: Do not apply localized formatting to NaN and inf [PR114863]Jonathan Wakely1-1/+1
We don't want to add grouping to strings like "-inf", and there is no radix character to replace either. libstdc++-v3/ChangeLog: PR libstdc++/114863 * include/std/format (__formatter_fp::format): Only use _M_localized for finite values. * testsuite/std/format/functions/format.cc: Check localized formatting of NaN and initiny. (cherry picked from commit 7501c0a397fcf609a1ff5f083746b6330b89ee11)
2024-04-25libstdc++: Fix typo in Doxygen commentJonathan Wakely1-1/+1
libstdc++-v3/ChangeLog: * include/std/chrono (tzdb_list): Fix typo in Doxygen comment.
2024-04-25libstdc++: Add comment to #include in <variant>Jonathan Wakely1-1/+1
It's not obvious why <variant> needs <bits/parse_numbers.h> so add a comment to it. libstdc++-v3/ChangeLog: * include/std/variant: Add comment to #include.
2024-04-17libstdc++: Implement "Printing blank lines with println" for C++23Jonathan Wakely2-0/+26
This was recently approved for C++26 at the Tokyo meeting. As suggested by Stephan T. Lavavej, I'm defining it as an extension for C++23 mode (when std::print and std::prinln were first added) rather than as a new C++26 feature. Both MSVC and libc++ have agreed to do this too. libstdc++-v3/ChangeLog: * include/std/ostream (println(ostream&)): Define new overload. * include/std/print (println(FILE*), println()): Likewise. * testsuite/27_io/basic_ostream/print/2.cc: New test. * testsuite/27_io/print/1.cc: Remove unused header. * testsuite/27_io/print/3.cc: New test.
2024-04-15libstdc++: Add std::reference_wrapper comparison operators for C++26Jonathan Wakely1-0/+1
This C++26 change was just approved in Tokyo, in P2944R3. It adds operator== and operator<=> overloads to std::reference_wrapper. The operator<=> overloads in the paper cause compilation errors for any type without <=> so they're implemented here with deduced return types and constrained by a requires clause. libstdc++-v3/ChangeLog: * include/bits/refwrap.h (reference_wrapper): Add comparison operators as proposed by P2944R3. * include/bits/version.def (reference_wrapper): Define. * include/bits/version.h: Regenerate. * include/std/functional: Enable feature test macro. * testsuite/20_util/reference_wrapper/compare.cc: New test.
2024-04-03libstdc++: Reverse arguments in constraint for std::optional's <=> [PR104606]Jonathan Wakely1-1/+1
This is a workaround for a possible compiler bug that causes constraint recursion in the operator<=>(const optional<T>&, const U&) overload. libstdc++-v3/ChangeLog: PR libstdc++/104606 * include/std/optional (operator<=>(const optional<T>&, const U&)): Reverse order of three_way_comparable_with template arguments. * testsuite/20_util/optional/relops/104606.cc: New test.
2024-04-02libstdc++: Allow adjacent __maybe_present_t<false, ...> fields to overlapPatrick Palka1-5/+8
Currently __maybe_present_t<false, T> maps to the same empty class type independent of T. This is suboptimal because it means adjacent __maybe_present_t<false, ...> members with the [[no_unique_address]] attribute can't overlap even if the conditionally present types are different. This patch turns this empty class type into a template parameterized by the conditionally present type, so that [[no_unique_address]] __maybe_present_t<false, T> _M_a; [[no_unique_address]] __maybe_present_t<false, U> _M_b; now overlap if T and U are different. This patch goes a step further and also adds an optional integer discriminator parameter to allow for overlapping when T and U are the same. libstdc++-v3/ChangeLog: * include/std/ranges (ranges::__detail::_Empty): Rename to ... (ranges::__detail::_Absent): ... this. Turn into a template parameterized by the absent type _Tp and discriminator _Disc. (ranges::__detail::__maybe_present_t): Add an optional discriminator parameter. (slide_view::_M_cached_begin): Pass a discriminator argument to __maybe_present_t. (slide_view::_M_cached_end): Likewise. * testsuite/std/ranges/adaptors/sizeof.cc: Verify the size of slide_view<V> is 3 instead 4 pointers. Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
2024-03-26libstdc++: fix generator iterator operator* return typeArsen Arsenović1-2/+2
Per the standard, the return type of a generators ranges iterator op* should be the reference type rather than the yielded type. The yielded type was used here by mistake. libstdc++-v3/ChangeLog: * include/std/generator (generator::_Iterator::operator*): Fix return type. * testsuite/24_iterators/range_generators/iter_deref_return.cc: New test.
2024-03-26libstdc++: fix _V badname in <generator>Arsen Arsenović1-8/+10
libstdc++-v3/ChangeLog: * include/std/generator: Fix _V badname.
2024-03-23libstdc++: Disable std::formatter specializations (LWG 3944)Jonathan Wakely1-0/+23
This was just approved in Tokyo as a DR for C++23. It doesn't affect us yet, because we don't implement the __cpp_lib_format_ranges features. We can add the disabled specializations and add a testcase now though. libstdc++-v3/ChangeLog: * include/std/format (formatter): Disable specializations that would allow sequences of narrow characters to be formatted as wchar_t without conversion, as per LWG 3944. * testsuite/std/format/formatter/lwg3944.cc: New test.
2024-03-23libstdc++: Add __is_in_place_index_v helper and use it in <variant>Jonathan Wakely1-1/+2
We already have __is_in_place_type_v for in_place_type_t so adding an equivalent for in_place_index_t allows us avoid a class template instantiation for the __not_in_place_tag constraint on the most commonly-used std::variant::variant(T&&) constructor. For in_place_type_t we also have a __is_in_place_type class template defined in terms of the variable template, but that isn't actually used anywhere. I'm not adding an equivalent for the new variable template, because that wouldn't be used either. For GCC 15 we should remove the unused __is_in_place_tag and __is_in_place_type class templates. libstdc++-v3/ChangeLog: * include/bits/utility.h (__is_in_place_index_v): New variable template. * include/std/variant (__not_in_place_tag): Define in terms of variable templates not a class template.
2024-03-23libstdc++: Use std::type_identity_t in <string_view> as per LWG 3950 [PR114400]Jonathan Wakely1-2/+10
The difference between __type_identity_t and std::type_identity_t is observable, as demonstrated in the PR. Nobody in LWG seems to think this an example we should really care about, but it seems easy and harmless to change this. libstdc++-v3/ChangeLog: PR libstdc++/114400 * include/std/string_view (operator==): Use std::type_identity_t in C++20 instead of our own __type_identity_t.
2024-03-22libstdc++: Replace std::result_of with __invoke_result_t [PR114394]Jonathan Wakely2-1/+5
Replace std::result_of with std::invoke_result, as specified in the standard since C++17, to avoid deprecated warnings for std::result_of. We don't have __invoke_result_t in C++11 mode, so add it as an alias template for __invoke_result<>::type (which is what std::result_of uses as its base class, so there's no change in functionality). This fixes warnings given by Clang 18. libstdc++-v3/ChangeLog: PR libstdc++/114394 * include/std/functional (bind): Use __invoke_result_t instead of result_of::type. * include/std/type_traits (__invoke_result_t): New alias template. * testsuite/20_util/bind/ref_neg.cc: Adjust prune pattern.
2024-03-14libstdc++: Fix std::format("{}", negative_integer) [PR114325]Jonathan Wakely1-3/+4
The fast path for "{}" format strings has a bug for negative integers where the length passed to std::to_chars is too long. libstdc++-v3/ChangeLog: PR libstdc++/114325 * include/std/format (_Scanner::_M_scan): Pass correct length to __to_chars_10_impl. * testsuite/std/format/functions/format.cc: Check negative integers with empty format-spec.
2024-03-07libstdc++: Do not define lock-free atomic aliases if not fully lock-free ↵Jonathan Wakely1-3/+3
[PR114103] The whole point of these typedefs is to guarantee lock-freedom, so if the target has no such types, we shouldn't defined the typedefs at all. libstdc++-v3/ChangeLog: PR libstdc++/114103 * include/bits/version.def (atomic_lock_free_type_aliases): Add extra_cond to check for at least one always-lock-free type. * include/bits/version.h: Regenerate. * include/std/atomic (atomic_signed_lock_free) (atomic_unsigned_lock_free): Only use always-lock-free types. * src/c++20/tzdb.cc (time_zone::_Impl::RulesCounter): Don't use atomic counter if lock-free aliases aren't available. * testsuite/29_atomics/atomic/lock_free_aliases.cc: XFAIL for targets without lock-free word-size compare_exchange.
2024-03-07libstdc++: Update expiry times for leap seconds listsJonathan Wakely1-1/+1
The list in tzdb.cc isn't the only hardcoded list of leap seconds in the library, there's the one defined inline in <chrono> (to avoid loading the tzdb for the common case) and another in a testcase. This updates them to note that there are no new leap seconds in 2024 either, until at least 2024-12-28. libstdc++-v3/ChangeLog: * include/std/chrono (__get_leap_second_info): Update expiry time for hardcoded list of leap seconds. * testsuite/std/time/tzdb/leap_seconds.cc: Update comment.
2024-03-07libstdc++: Better diagnostics for std::format errorsJonathan Wakely1-0/+13
This adds two new static_assert messages to the internals of std::make_format_args to give better diagnostics for invalid format args. Rather than just getting an error saying that basic_format_arg cannot be constructed, we get more specific errors for the cases where std::formatter isn't specialized for the type at all, and where it's specialized but only meets the BasicFormatter requirements and so can only format non-const arguments. Also add a test for the existing static_assert when constructing a format_string for non-formattable args. libstdc++-v3/ChangeLog: * include/std/format (_Arg_store::_S_make_elt): Add two static_assert checks to give more user-friendly error messages. * testsuite/lib/prune.exp (libstdc++-dg-prune): Prune another form of "in requirements with" note. * testsuite/std/format/arguments/args_neg.cc: Check for user-friendly diagnostics for non-formattable types. * testsuite/std/format/string_neg.cc: Likewise.
2024-03-04libstdc++: Add missing std::tuple constructor [PR114147]Jonathan Wakely1-0/+14
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.
2024-02-29libstdc++: Fix std::basic_format_arg::handle for BasicFormattersJonathan Wakely1-5/+1
std::basic_format_arg::handle is supposed to format its value as const if that is valid, to reduce the number of instantiations of the formatter's format function. I made a silly typo so that it checks formattable_with<TD, Context> not formattable_with<const TD, Context>, which breaks support for BasicFormatters i.e. ones that can only format non-const types. There's a static_assert in the handle constructor which is supposed to improve diagnostics for trying to format a const argument with a formatter that doesn't support it. That condition can't fail, because the std::basic_format_arg constructor is already constrained to check that the argument type is formattable. The static_assert can be removed. libstdc++-v3/ChangeLog: * include/std/format (basic_format_arg::handle::__maybe_const_t): Fix condition to check if const type is formattable. (basic_format_arg::handle::handle(T&)): Remove redundant static_assert. * testsuite/std/format/formatter/basic.cc: New test.
2024-02-28libstdc++: Consistently use noexcept, constexpr, nodiscard on bitmask opsJonathan Wakely2-0/+11
The bitwise operators for combining bitmask types such as std::launch are not consistently annotated with noexcept, constexpr, and nodiscard. This is the subject of LWG 3977, although the proposed resolution doesn't work. We can make the changes in libstdc++ anyway though. libstdc++-v3/ChangeLog: * include/bits/atomic_base.h (operator|, operator&): Add noexcept. * include/bits/fs_fwd.h (operator&, operator|, operator^) (operator~): Add nodiscard to overloads for copy_options, perms, perm_options, and directory_options. * include/bits/ios_base.h (operator&, operator|, operator^) (operator~): Add nodiscard and noexcept to overloads for _Ios_Fmtflags, _Ios_Openmode, and _Ios_Iostate. (operator|=, operator&=, operator^=): Add constexpr for C++14. * include/bits/regex_constants.h (operator&, operator|, operator^) (operator~): Add nodiscard and noexcept to overloads for syntax_option_type and match_flag_type. (operator|=, operator&=, operator^=): Add noexcept. * include/std/charconv (operator&, operator|, operator^) (operator~): Add nodiscard to overloads for chars_format. * include/std/future (operator&, operator|, operator^) (operator~): Add nodiscard for overloads for launch. (operator&=, operator|=, operator^=): Add constexpr for C++14. * include/experimental/bits/fs_fwd.h (operator&, operator|) (operator^, operator~): Add nodiscard to overloads for copy_options, perms, and directory_options. * testsuite/27_io/ios_base/types/fmtflags/bitmask_operators.cc: Add dg-warning for nodiscard warnings. * testsuite/27_io/ios_base/types/iostate/bitmask_operators.cc: Likewise. * testsuite/27_io/ios_base/types/openmode/bitmask_operators.cc: Likewise. * testsuite/27_io/filesystem/operations/bitmask_types.cc: New test.
2024-02-28libstdc++: Fix std::print for CygwinJonathan Wakely2-3/+3
Cygwin should use std::fwrite, not WriteConsoleW. And the -lstdc++exp library is only needed when running the tests on *-*-mingw*. libstdc++-v3/ChangeLog: * include/std/ostream (vprint_unicode) [__CYGWIN__]: Use POSIX code path for Cygwin instead of Windows. * include/std/print (vprint_unicode) [__CYGWIN__]: Likewise. * testsuite/27_io/basic_ostream/print/1.cc: Only add -lstdc++exp for *-*-mingw* targets. * testsuite/27_io/print/1.cc: Likewise.
2024-02-28libstdc++: Add more [[nodiscard]] to <stacktrace>Jonathan Wakely1-5/+31
libstdc++-v3/ChangeLog: * include/std/stacktrace: Add nodiscard attribute to all functions without side effects.
2024-02-15libstdc++: Remove redundant zeroing in std::bitset::operator>>= [PR113806]Jonathan Wakely1-4/+1
The unused bits in the high word are already zero before this operation. Shifting the used bits to the right cannot affect the unused bits, so we don't need to sanitize them. libstdc++-v3/ChangeLog: PR libstdc++/113806 * include/std/bitset (bitset::operator>>=): Remove redundant call to _M_do_sanitize.
2024-02-15libstdc++: Use memset to optimize std::bitset::set() [PR113807]Jonathan Wakely1-2/+9
As pointed out in the PR we already do this for reset(). libstdc++-v3/ChangeLog: PR libstdc++/113807 * include/std/bitset (bitset::set()): Use memset instead of a loop over the individual words.
2024-02-15libstdc++: Avoid aliasing violation in std::valarray [PR99117]Jonathan Wakely1-1/+7
The call to __valarray_copy constructs an _Array object to refer to this->_M_data but that means that accesses to this->_M_data are through a restrict-qualified pointer. This leads to undefined behaviour when copying from an _Expr object that actually aliases this->_M_data. Replace the call to __valarray_copy with a plain loop. I think this removes the only use of that overload of __valarray_copy, so it could probably be removed. I haven't done that here. libstdc++-v3/ChangeLog: PR libstdc++/99117 * include/std/valarray (valarray::operator=(const _Expr&)): Use loop to copy instead of __valarray_copy with _Array. * testsuite/26_numerics/valarray/99117.cc: New test.
2024-02-09libstdc++: Use _GLIBCXX_USE_BUILTIN_TRAIT for is_sameKen Matsui1-4/+5
Since is_same has a fallback native implementation, and _GLIBCXX_HAVE_BUILTIN_IS_SAME does not support toggling which implementation to use, we remove the _GLIBCXX_HAVE_BUILTIN_IS_SAME definition and use _GLIBCXX_USE_BUILTIN_TRAIT instead. libstdc++-v3/ChangeLog: * include/bits/c++config (_GLIBCXX_HAVE_BUILTIN_IS_SAME): Removed. * include/std/type_traits (is_same): Use _GLIBCXX_USE_BUILTIN_TRAIT instead of _GLIBCXX_HAVE_BUILTIN_IS_SAME. (is_same_v): Likewise. Signed-off-by: Ken Matsui <kmatsui@gcc.gnu.org> Reviewed-by: Patrick Palka <ppalka@redhat.com> Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
2024-02-04libstdc++: Replace padding bits with bit-fields in __format::_SpecJonathan Wakely1-0/+2
This ensures that the unused bits will be zero-initialized reliably, and so can be used later by assigning them values in formatter specializations. For example, formatters for std::chrono will need to use an extra bit for a boolean flag to optimize the conversions between locale encodings and UTF-8. Adding the 16-bit _M_reserved2 bit-field results in an increased size for targets that use 1- or 2-byte alignment for all integral types, e.g. cris-elf or m68k. Placing that member before the _M_width member adjusts the layout for all targets, but keeps all the bit-fields together. We can't make that change once C++20 support is ABI stable and non-experimental, so do it now before GCC 14 is released. The _M_fill data member already change from char to char32_t in r14-6991-g37a4c5c23a270c so _Spec is already incompatible with gcc-13 anyway. libstdc++-v3/ChangeLog: * include/std/format (__format::_Spec::_M_reserved): Define new bit-field members to reserve padding bits for future extensions.
2024-02-02libstdc++: Allow explicit conversion of string views with different traitsJonathan Wakely1-2/+0
This was changed by LWG 3857. libstdc++-v3/ChangeLog: * include/std/string_view (basic_string_view(R&&)): Remove constraint that traits_type must be the same, as per LWG 3857. * testsuite/21_strings/basic_string_view/cons/char/range_c++20.cc: Explicit conversion between different specializations should be allowed. * testsuite/21_strings/basic_string_view/cons/wchar_t/range_c++20.cc: Likewise.
2024-02-02libstdc++: Remove noexcept from std::osyncstream::operator=Jonathan Wakely1-1/+1
This should not be noexcept because its _M_syncbuf member has a potentially-throwing move assignment operator. The noexcept was removed by LWG 3867. libstdc++-v3/ChangeLog: * include/std/syncstream (basic_osyncstream::operator=): Remove noexcept, as per LWG 3867.
2024-02-02libstdc++: Remove noexcept from std::generator::promise_type::yield_valueJonathan Wakely1-1/+0
This overload of std::generator::promise_type::yield_value calls things which might throw, so should not be noexcept. The noexcept was remove by LWG 3894. libstdc++-v3/ChangeLog: * include/std/generator (promise_type::yield_value): Remove noexcept from fourth overload, as per LWG 3894.
2024-02-01libstdc++: Implement P2165R4 changes to std::pair/tuple/etc [PR113309]Patrick Palka6-76/+311
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>
2024-01-31libstdc++: Fix -Wshift-count-overflow warning in std::bitsetJonathan Wakely1-6/+7
This shift only happens if the unsigned long long type is wider than unsigned long but the compiler warns when it sees the shift, without caring if it's reachable. Use the preprocessor to compare the sizes and just reuse _M_to_ulong() if sizeof(long) == sizeof(long long). libstdc++-v3/ChangeLog: * include/std/bitset (_Base_bitset::_M_do_to_ullong): Avoid -Wshift-count-overflow warning.
2024-01-21libstdc++: Fix std::format floating-point alternate forms [PR113512]Jonathan Wakely1-16/+35
The logic for handling '#' forms was ... not good. The count of significant figures just counted digits, instead of ignoring leading zeros. And when moving the result from the stack buffer to a dynamic string the exponent could get lost in some cases. libstdc++-v3/ChangeLog: PR libstdc++/113512 * include/std/format (__formatter_fp::format): Fix logic for alternate forms. * testsuite/std/format/functions/format.cc: Check buggy cases of alternate forms with g presentation type.
2024-01-20libstdc++: suppress -Wdangling-reference with operator| [PR111410]Marek Polacek1-0/+3
It seems to me that we should exclude std::ranges::views::__adaptor::operator| from the -Wdangling-reference warning. It's commonly used when handling ranges. PR c++/111410 libstdc++-v3/ChangeLog: * include/std/ranges: Add #pragma to disable -Wdangling-reference with std::ranges::views::__adaptor::operator|. gcc/testsuite/ChangeLog: * g++.dg/warn/Wdangling-reference17.C: New test.
2024-01-19libstdc++: Do not use CTAD for _Utf32_view alias template (redux)Jonathan Wakely1-1/+1
My change in r14-8181-g665a3ff1539ce2 was incomplete as there's a second place using CTAD with the _Utf32_view alias template. This fixes it. libstdc++-v3/ChangeLog: * include/std/format (_Spec::_M_parse_fill_and_align): Do not use CTAD for _Utf32_view.
2024-01-19libstdc++: Fix P2255R2 dangling checks for std::tuple in C++17 [PR108822]Jonathan Wakely1-1/+1
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.
2024-01-18libstdc++/tuple: Guard P2321R2 changes with __cpp_lib_ranges_zipPatrick Palka1-9/+9
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>
2024-01-17libstdc++: Implement C++26 std::text_encoding (P1885R12) [PR113318]Jonathan Wakely1-0/+678
This is another C++26 change, approved in Varna 2023. We require a new static array of data that is extracted from the IANA Character Sets database. A new Python script to generate a header from the IANA CSV file is added. The text_encoding class is basically just a pointer to an {ID,name} pair in the static array. The aliases view is also just the same pointer (or empty), and the view's iterator moves forwards and backwards in the array while the array elements have the same ID (or to one element further, for a past-the-end iterator). Because those iterators refer to a global array that never goes out of scope, there's no reason they should every produce undefined behaviour or indeterminate values. They should either have well-defined behaviour, or abort. The overhead of ensuring those properties is pretty low, so seems worth it. This means that an aliases_view iterator should never be able to access out-of-bounds. A non-value-initialized iterator always points to an element of the static array even when not dereferenceable (the array has unreachable entries at the start and end, which means that even a past-the-end iterator for the last encoding in the array still points to valid memory). Dereferencing an iterator can always return a valid array element, or "" for a non-dereferenceable iterator (but doing so will abort when assertions are enabled). In the language being proposed for C++26, dereferencing an invalid iterator erroneously returns "". Attempting to increment/decrement past the last/first element in the view is erroneously a no-op, so aborts when assertions are enabled, and doesn't change value otherwise. Similarly, constructing a std::text_encoding with an invalid id (one that doesn't have the value of an enumerator) erroneously behaves the same as constructing with id::unknown, or aborts with assertions enabled. libstdc++-v3/ChangeLog: PR libstdc++/113318 * acinclude.m4 (GLIBCXX_CONFIGURE): Add c++26 directory. (GLIBCXX_CHECK_TEXT_ENCODING): Define. * config.h.in: Regenerate. * configure: Regenerate. * configure.ac: Use GLIBCXX_CHECK_TEXT_ENCODING. * include/Makefile.am: Add new headers. * include/Makefile.in: Regenerate. * include/bits/locale_classes.h (locale::encoding): Declare new member function. * include/bits/unicode.h (__charset_alias_match): New function. * include/bits/text_encoding-data.h: New file. * include/bits/version.def (text_encoding): Define. * include/bits/version.h: Regenerate. * include/std/text_encoding: New file. * src/Makefile.am: Add new subdirectory. * src/Makefile.in: Regenerate. * src/c++26/Makefile.am: New file. * src/c++26/Makefile.in: New file. * src/c++26/text_encoding.cc: New file. * src/experimental/Makefile.am: Include c++26 convenience library. * src/experimental/Makefile.in: Regenerate. * python/libstdcxx/v6/printers.py (StdTextEncodingPrinter): New printer. * scripts/gen_text_encoding_data.py: New file. * testsuite/22_locale/locale/encoding.cc: New test. * testsuite/ext/unicode/charset_alias_match.cc: New test. * testsuite/std/text_encoding/cons.cc: New test. * testsuite/std/text_encoding/members.cc: New test. * testsuite/std/text_encoding/requirements.cc: New test. Reviewed-by: Ulrich Drepper <drepper.fsp@gmail.com> Reviewed-by: Patrick Palka <ppalka@redhat.com>
2024-01-16libstdc++: Implement P2540R1 change to views::cartesian_product()Patrick Palka1-1/+1
This paper changes the identity element of views::cartesian_product to a singleton range instead of an empty range. It was approved alongside the main cartesian_product paper P2374R4, but unfortunately was overlooked when implementing the main paper. libstdc++-v3/ChangeLog: * include/std/ranges (views::_CartesianProduct::operator()): Adjust identity case as per P2540R1. * testsuite/std/ranges/cartesian_product/1.cc (test01): Adjust expected result of the identity case. Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
2024-01-15libstdc++: Reduce std::variant template instantiation depthPatrick Palka1-8/+7
The recursively defined constraints on _Variadic_union's user-defined destructor (used for maintaining trivial destructibility of the variant iff all of its alternatives are) turn out to require a template instantiation depth of 3x the number of variants in C++20 mode, with the instantiation stack looking like ... _Variadic_union<B, C, ...> std::is_trivially_destructible_v<_Variadic_union<B, C, ...>> _Variadic_union<A, B, C, ...>::~_Variadic_union() _Variadic_union<A, B, C, ...> ... Ideally the template depth should be ~equal to the number of variants (plus a constant). Luckily it seems we don't need to compute trivial destructibility of the alternatives at all from _Variadic_union, since its only user _Variant_storage already has that information. To that end this patch removes these recursive constraints and instead passes this information down from _Variant_storage. After this patch, the template instantiation depth for 87619.cc in C++20 mode is ~270 instead of ~780. libstdc++-v3/ChangeLog: * include/std/variant (__detail::__variant::_Variadic_union): Add bool __trivially_destructible template parameter. (__detail::__variant::_Variadic_union::~_Variadic_union): Use __trivially_destructible in constraints instead. (__detail::__variant::_Variant_storage): Pass __trivially_destructible value to _Variadic_union. Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
2024-01-15libstdc++: Fix redefinition error in std::tuple [PR108822]Jonathan Wakely1-16/+19
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.
2024-01-15libstdc++: Use variable template to fix -fconcepts-ts error [PR113366]Jonathan Wakely1-3/+2
There's an error for -fconcepts-ts due to using a concept where a bool NTTP is required, which is fixed by using the vraiable template that already exists in the class scope. This doesn't fix the problem with -fconcepts-ts as changes to the placement of attributes is also needed. libstdc++-v3/ChangeLog: PR testsuite/113366 * include/std/format (basic_format_arg): Use __formattable variable template instead of __format::__formattable_with concept.
2024-01-13libstdc++: Implement P2255R2 dangling checks for std::tuple [PR108822]Jonathan Wakely2-294/+734
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>
2024-01-12libstdc++: Implement C++23 std::bind_back from P2387R3 [PR108827]Patrick Palka1-0/+70
The implementation is based off of std::bind_front. Since this is a C++23 feature we use deducing this unconditionally. PR libstdc++/108827 PR libstdc++/111327 libstdc++-v3/ChangeLog: * include/bits/version.def (bind_back): Define. * include/bits/version.h: Regenerate. * include/std/functional (_Bind_back): Define for C++23. (bind_back): Likewise. * testsuite/20_util/function_objects/bind_back/1.cc: New test (adapted from corresponding bind_front test). * testsuite/20_util/function_objects/bind_back/111327.cc: Likewise.