aboutsummaryrefslogtreecommitdiff
path: root/libstdc++-v3/include/bits
AgeCommit message (Collapse)AuthorFilesLines
17 hoursRevert "libstdc++: Optimize std::projected<I, std::identity>" [PR119888]Patrick Palka1-5/+0
This non-standard optimization breaks real-world code that expects the result of std::projected to always (be a class type and) have a value_type member, which isn't true for e.g. I=int*, so revert it for now. PR libstdc++/119888 This reverts commit 51761c50f843d5be4e24172535e4524b5072f24c.
8 dayslibstdc++: Fix std::string construction from volatile char* [PR119748]Jonathan Wakely3-13/+31
My recent r15-9381-g648d5c26e25497 change assumes that a contiguous iterator with the correct value_type can be converted to a const charT* but that's not true for volatile charT*. The optimization should only be done if it can be converted to the right pointer type. Additionally, some generic loops for non-contiguous iterators need an explicit cast to deal with iterator reference types that do not bind to the const charT& parameter of traits_type::assign. libstdc++-v3/ChangeLog: PR libstdc++/119748 * include/bits/basic_string.h (_S_copy_chars): Only optimize for contiguous iterators that are convertible to const charT*. Use explicit conversion to charT after dereferencing iterator. (_S_copy_range): Likewise for contiguous ranges. * include/bits/basic_string.tcc (_M_construct): Use explicit conversion to charT after dereferencing iterator. * include/bits/cow_string.h (_S_copy_chars): Likewise. (basic_string(from_range_t, R&&, const Allocator&)): Likewise. Only optimize for contiguous iterators that are convertible to const charT*. * testsuite/21_strings/basic_string/cons/char/119748.cc: New test. * testsuite/21_strings/basic_string/cons/wchar_t/119748.cc: New test. Reviewed-by: Tomasz Kaminski <tkaminsk@redhat.com>
12 dayslibstdc++: Use constexpr-if for std::basic_string::_S_copy_charsJonathan Wakely1-8/+23
For C++11 and later we can remove four overloads of _S_copy_chars and use constexpr-if in the generic _S_copy_chars. This simplifies overload resolution for _S_copy_chars, and also means that we use the optimized memcpy path for other iterators such as std::vector<char>::iterator. We still need all the _S_copy_chars overloads to be part of the explicit instantiation definition, so make them depend on the macro that is defined by src/c++11/string-inst.cc for that purpose. For C++98 the _S_copy_chars overloads are still needed, but the macros _GLIBCXX_NOEXCEPT and _GLIBCXX20_CONSTEXPR do nothing for C++98, so this change removes them from those overloads. When instantiated in src/c++11/string-inst.cc the removed _GLIBCXX_NOEXCEPT macros would expand to 'noexcept', but in practice that doesn't make any difference for those instantiations. At -O2 the instantiations inline all the calls to _S_copy_chars and the presence or absence of noexcept doesn't change anything in the generated code. libstdc++-v3/ChangeLog: * include/bits/basic_string.h (_S_copy_chars): Replace overloads with constexpr-if and extend optimization to all contiguous iterators. * src/c++11/string-inst.cc: Extend comment. Reviewed-by: Tomasz Kaminski <tkaminsk@redhat.com>
12 dayslibstdc++: Define __cpp_lib_containers_ranges in appropriate headers [PR111055]Tomasz Kamiński20-101/+113
This is final piece of P1206R7, adding a feature test macros, as range constructors and member operations are now implemented for all containers and adaptors. For consistency with the proposal, all new container operations and helpers are now defined if __glibcxx_containers_ranges, instead of __glibcxx_ranges_to_container. PR libstdc++/111055 libstdc++-v3/ChangeLog: * include/bits/version.def (containers_ranges): Define. * include/bits/version.h: Regenerate. * include/bits/ranges_base.h (__detail::__container_compatible_range) (__detail::__range_to_alloc_type, __detail::__range_mapped_type) (__detail::__range_key_type): Depend on __glibcxx_containers_ranges instead of __glibcxx_ranges_to_container. * include/bits/basic_string.h: Replace __glibcxx_ranges_to_container with __glibcxx_containers_ranges. * include/bits/cow_string.h: Likewise. * include/bits/deque.tcc: Likewise. * include/bits/forward_list.h: Likewise. * include/bits/stl_bvector.h: Likewise. * include/bits/stl_deque.h: Likewise. * include/bits/stl_list.h: Likewise. * include/bits/stl_map.h: Likewise. * include/bits/stl_multimap.h: Likewise. * include/bits/stl_multiset.h: Likewise. * include/bits/stl_queue.h: Likewise. * include/bits/stl_set.h: Likewise. * include/bits/stl_stack.h: Likewise. * include/bits/stl_vector.h: Likewise. * include/bits/unordered_map.h: Likewise. * include/bits/unordered_set.h: Likewise. * include/bits/vector.tcc: Likewise. * include/debug/deque: Likewise. * include/debug/forward_list: Likewise. * include/debug/list: Likewise. * include/debug/map.h: Likewise. * include/debug/multimap.h: Likewise. * include/debug/multiset.h: Likewise. * include/debug/set.h: Likewise. * include/debug/unordered_map: Likewise. * include/debug/unordered_set: Likewise. * include/debug/vector: Likewise. * include/std/deque: Provide __cpp_lib_containers_ranges. * include/std/forward_list: Likewise. * include/std/list: Likewise. * include/std/map: Likewise. * include/std/queue: Likewise. * include/std/set: Likewise. * include/std/stack: Likewise. * include/std/string: Likewise. * include/std/unordered_map: Likewise. * include/std/unordered_set: Likewise. * include/std/vector: Likewise. * testsuite/21_strings/basic_string/cons/from_range.cc: Test for value __cpp_lib_containers_ranges. * testsuite/23_containers/deque/cons/from_range.cc: Likewise. * testsuite/23_containers/forward_list/cons/from_range.cc: Likewise. * testsuite/23_containers/list/cons/from_range.cc: Likewise. * testsuite/23_containers/map/cons/from_range.cc: Likewise. * testsuite/23_containers/multimap/cons/from_range.cc: Likewise. * testsuite/23_containers/multiset/cons/from_range.cc: Likewise. * testsuite/23_containers/priority_queue/cons_from_range.cc: Likewise. * testsuite/23_containers/queue/cons_from_range.cc: Likewise. * testsuite/23_containers/set/cons/from_range.cc: Likewise. * testsuite/23_containers/stack/cons_from_range.cc: Likewise. * testsuite/23_containers/unordered_map/cons/from_range.cc: Likewise. * testsuite/23_containers/unordered_multimap/cons/from_range.cc: Likewise. * testsuite/23_containers/unordered_multiset/cons/from_range.cc: Likewise. * testsuite/23_containers/unordered_set/cons/from_range.cc: Likewise. * testsuite/23_containers/vector/bool/cons/from_range.cc: Likewise. * testsuite/23_containers/vector/cons/from_range.cc: Likewise. Reviewed-by: Jonathan Wakely <jwakely@redhat.com> Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
12 dayslibstdc++: Add P1206R7 from_range members to std::string [PR111055]Jonathan Wakely2-0/+297
This is the last piece of P1206R7, adding new members to std::basic_string. libstdc++-v3/ChangeLog: PR libstdc++/111055 * include/bits/basic_string.h (_S_copy_range): New function. (basic_string(from_range_t, R%%, const Alloc&)): New constructor. (append_range, assign_range, insert_range, replace_with_range): New functions. * include/bits/cow_string.h: Likewise. * testsuite/21_strings/basic_string/cons/from_range.cc: New test. * testsuite/21_strings/basic_string/modifiers/append/append_range.cc: New test. * testsuite/21_strings/basic_string/modifiers/assign/assign_range.cc: New test. * testsuite/21_strings/basic_string/modifiers/insert/insert_range.cc: New test. * testsuite/21_strings/basic_string/modifiers/replace/replace_with_range.cc: New test. Co-authored-by: Tomasz Kamiński <tkaminsk@redhat.com>
12 dayslibstdc++: Implement debug format for strings and characters formatters ↵Tomasz Kamiński3-19/+274
[PR109162] This patch implements part P2286R8 that specified debug (escaped) format for the strings and characters sequences. This include both handling of the '?' format specifier and set_debug_format member. To indicate partial support we define __glibcxx_format_ranges macro value 1, without defining __cpp_lib_format_ranges. We provide two separate escaping routines depending on the literal encoding for the corresponding character types. If the character encoding is Unicode, we follow the specification for the standard (__format::__write_escaped_unicode). For other encodings, we escape only characters in range [0x00, 0x80), interpreting them as ASCII values: [0x00, 0x20), 0x7f and '\t', '\r', '\n', '\\', '"', '\'' are escaped. We assume every character outside this range is printable (__format::_write_escaped_ascii). In particular we do not yet implement special handling of shift sequences. For Unicode escaping a new __unicode::__escape_edges table is introduced, that encodes information if character belongs to General_Category that is escaped by the standard (Control or Other). This table is generated from DerivedGeneralCategory.txt provided by Unicode. Only boolean flag is preserved to reduce the number of entries. The additional rules for escaping are handled by __format::__should_escape_unicode. When width or precision is specified, we emit escaped string to the temporary buffer and format the resulting string according to the format spec. For characters use a fixed size stack buffer, for which a new _Fixedbuf_sink is introduced. For strings, we use _Str_sink and to avoid allocations, we compute the estimated size of (possibly truncated) input, and if it is larger than width field we print directly. PR libstdc++/109162 contrib/ChangeLog: * unicode/README: Mentioned DerivedGeneralCategory.txt. * unicode/gen_libstdcxx_unicode_data.py: Generation __escape_edges table from DerivedGeneralCategory.txt. Update file name in comments. * unicode/DerivedGeneralCategory.txt: Copy of file distributed by Unicode Consortium. libstdc++-v3/ChangeLog: * include/bits/chrono_io.h (__detail::_Widen): Moved to std/format file. * include/bits/unicode-data.h: Regnerate. * include/bits/unicode.h (__unicode::_Utf_iterator::_M_units) (__unicode::__should_escape_category): Define. * include/std/format (_GLIBCXX_WIDEN_, _GLIBCXX_WIDEN): Copied from include/bits/chrono_io.h. (__format::_Widen): Moved from include/bits/chrono_io.h. (__format::_Term_char, __format::_Escapes, __format::_Separators) (__format::__should_escape_ascii, __format::__should_escape_unicode) (__format::__write_escape_seq, __format::__write_escaped_char) (__format::__write_escaped_acii, __format::__write_escaped_unicode) (__format::__write_escaped): Define. (__formatter_str::_S_trunc): Extracted truncation of character sequences. (__formatter_str::format): Handle _Pres_esc. (__formatter_int::_M_do_parse) [__glibcxx_format_ranges]: Parse '?'. (__formatter_int::_M_format_character_escaped): Define. (formatter<_CharT, _CharT>::format, formatter<char, wchar_t>::format): Handle _Pres_esc. (__formatter_str::set_debug_format, formatter<...>::set_debug_format) Guard with __glibcxx_format_ranges. (__format::_Fixedbuf_sink): Define. * testsuite/23_containers/vector/bool/format.cc: Use __format::_Widen and remove unnecessary <chrono> include. * testsuite/std/format/debug.cc: New test. * testsuite/std/format/debug_nonunicode.cc: New test. * testsuite/std/format/parse_ctx.cc (escaped_strings_supported): Define to true if __glibcxx_format_ranges is defined. * testsuite/std/format/string.cc (escaped_strings_supported): Define to true if __glibcxx_format_ranges is defined. Reviewed-by: Jonathan Wakely <jwakely@redhat.com> Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
13 dayslibstdc++: Adjust value of __cpp_lib_constrained_equality for C++20Jonathan Wakely2-2/+12
The P3379R0 bump to __cpp_lib_constrained_equality relates to changes that only affect std::expected, so there's no reason to define the updated value in C++20. This change restores the previous value (202403) for C++20, and only uses the new value (202411) for C++23 and later. Also remove the TODO comments, because I correctly predicted that the final value would be 202411. libstdc++-v3/ChangeLog: * include/bits/version.def (constrained_equality): Only define as 202411 for C++23 and later, use 202403 for C++20. * include/bits/version.h: Regenerate. * testsuite/20_util/expected/equality_constrained.cc: Remove TODO comment.
13 dayslibstdc++: Fix constraint recursion in basic_const_iterator operator- [PR115046]Patrick Palka1-2/+2
It was proposed in PR112490 to also adjust basic_const_iterator's friend operator-(sent, iter) overload alongside the r15-7757-g4342c50ca84ae5 adjustments to its comparison operators, but we lacked a concrete testcase demonstrating fixable constraint recursion there. It turns out Hewill Kang's PR115046 is such a testcase! So this patch makes the same adjustments to that overload as well, fixing PR115046. The LWG 4218 P/R will need to get adjusted too. PR libstdc++/115046 PR libstdc++/112490 libstdc++-v3/ChangeLog: * include/bits/stl_iterator.h (basic_const_iterator::operator-): Replace non-dependent basic_const_iterator function parameter with a dependent one of type basic_const_iterator<_It2> where _It2 matches _It. * testsuite/std/ranges/adaptors/as_const/1.cc (test04): New test. Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
2025-04-07libstdc++: Remove stray pragma in new header [PR119642]Jonathan Wakely1-1/+0
libstdc++-v3/ChangeLog: PR libstdc++/119642 * include/bits/formatfwd.h: Remove stray pragma.
2025-04-04libstdc++: Replace use of __mindist in ranges::uninitialized_xxx algos ↵Jonathan Wakely1-32/+14
[PR101587] In r15-8980-gf4b6acfc36fb1f I introduced a new function object for finding the smaller of two distances. In bugzilla Hewill Kang pointed out that we still need to explicitly convert the result back to the right difference type, because the result might be an integer-like class type that doesn't convert to an integral type explicitly. Rather than doing that conversion in the __mindist function object, I think it's simpler to remove it again and just do a comparison and assignment. We always want the result to have a specific type, so we can just check if the value of the other type is smaller, and then convert that to the other type if so. libstdc++-v3/ChangeLog: PR libstdc++/101587 * include/bits/ranges_uninitialized.h (__detail::__mindist): Remove. (ranges::uninitialized_copy, ranges::uninitialized_copy_n) (ranges::uninitialized_move, ranges::uninitialized_move_n): Use comparison and assignment instead of __mindist. * testsuite/20_util/specialized_algorithms/uninitialized_copy/constrained.cc: Check with ranges that use integer-like class type for difference type. * testsuite/20_util/specialized_algorithms/uninitialized_move/constrained.cc: Likewise. Reviewed-by: Tomasz Kaminski <tkaminsk@redhat.com> Reviewed-by: Hewill Kang <hewillk@gmail.com>
2025-04-04libstdc++: Provide formatter for vector<bool>::reference [PR109162]Tomasz Kamiński3-9/+89
This patch implement formatter for vector<bool>::reference which is part of P2286R8. To indicate partial support we define __glibcxx_format_ranges macro value 1, without defining __cpp_lib_format_ranges. To avoid including the whole content of the <format> header, we introduce new bits/formatfwd.h forward declares classes required for newly introduce formatter. The signatures of the user-facing parse and format method of the provided formatters deviate from the standard by constraining types of params: * _Bit_reference instead T satisfying is-vector-bool-reference<T> * _CharT is constrained __formatter::__char * basic_format_parse_context<_CharT> for parse argument * basic_format_context<_Out, _CharT> for format second argument The standard specifies last three of above as unconstrained types, which leads to formattable<vector<bool>::reference, char32_t> (and any other type as char) being true. PR libstdc++/109162 libstdc++-v3/ChangeLog: * include/Makefile.am: Add bits/formatfwd.h. * include/Makefile.in: Add bits/formatfwd.h. * include/bits/version.def: Define __glibcxx_format_ranges without corresponding std name. * include/bits/version.h: Regenerate. * include/std/format (basic_format_context, __format::__char): Move declartions to bits/formatfwd.h. (formatter<_Tp, _CharT>): Remove default argument for _CharT parameter, now specified in forward declaration in bits/formatfwd.h. * include/std/vector (formatter<_Bit_reference, _CharT>): Define. * include/bits/formatfwd.h: New file with forward declarations for bits of std/format. * testsuite/23_containers/vector/bool/format.cc: New test. Reviewed-by: Jonathan Wakely <jwakely@redhat.com> Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
2025-04-04libstdc++: Check feature test macro for std::string_view in <string>Jonathan Wakely2-34/+35
We can use the __glibcxx_string_view macro to guard the uses of std::string_view in <string>, instead of just checking the value of __cplusplus. It makes no practical difference because __glibcxx_string_view is defined for C++17 and up, but it makes it clear to readers that the lines guarded by that macro are features that depend on string_view. We could be more precise and check __glibcxx_string_view >= 201606L which is the value for the P0254R2 paper that integrated std::string_view with std::string, but I think just checking for the macro being defined is clear enough. We can also check __glibcxx_variant for the _Never_valueless_alt partial specialization. libstdc++-v3/ChangeLog: * include/bits/basic_string.h: Check __glibcxx_string_view and __glibcxx_variant instead of __cplusplus >= 2017L. * include/bits/cow_string.h: Likewise. Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
2025-04-04libstdc++: Fix whitespace in std::basic_string::_M_construct<bool>Jonathan Wakely1-2/+2
libstdc++-v3/ChangeLog: * include/bits/basic_string.tcc: Fix whitespace.
2025-04-04libstdc++: allow defining version FTMs without standard-named macrosArsen Arsenović2-3/+7
This is useful to provide libstdc++-internal-only macros. libstdc++-v3/ChangeLog: * include/bits/version.tpl: Implement no_stdname. * include/bits/version.def: Document no_stdname.
2025-04-03libstdc++: Fix handling of field width for wide strings and characters ↵Tomasz Kamiński1-0/+2
[PR119593] This patch corrects handling of UTF-32LE and UTF32-BE in __unicode::__literal_encoding_is_unicode<_CharT>, so they are recognized as unicode and functions produces correct result for wchar_t. Use `__unicode::__field_width` to compute the estimated witdh of the charcter for unicode wide encoding. PR libstdc++/119593 libstdc++-v3/ChangeLog: * include/bits/unicode.h (__unicode::__literal_encoding_is_unicode<_CharT>): Corrected handing for UTF-16 and UTF-32 with "LE" or "BE" suffix. * include/std/format (__formatter_str::_S_character_width): Define. (__formatter_str::_S_character_width): Updated passed char length. * testsuite/std/format/functions/format.cc: Test for wchar_t. Reviewed-by: Jonathan Wakely <jwakely@redhat.com> Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
2025-04-01libstdc++: Fix -Warray-bounds warning in std::vector::resize [PR114945]Jonathan Wakely1-0/+3
This is yet another false positive warning fix. This time the compiler can't prove that when the vector has sufficient excess capacity to append new elements, the pointer to the existing storage is not null. libstdc++-v3/ChangeLog: PR libstdc++/114945 * include/bits/vector.tcc (vector::_M_default_append): Add unreachable condition so the compiler knows that _M_finish is not null. * testsuite/23_containers/vector/capacity/114945.cc: New test. Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
2025-03-31libstdc++: Fix -Warray-bounds warning in std::vector<bool> [PR110498]Jonathan Wakely1-1/+4
In this case, we need to tell the compiler that the current size is not larger than the new size so that all the existing elements can be copied to the new storage. This avoids bogus warnings about overflowing the new storage when the compiler can't tell that that cannot happen. We might as well also hoist the loads of begin() and end() before the allocation too. All callers will have loaded at least begin() before calling _M_reallocate. libstdc++-v3/ChangeLog: PR libstdc++/110498 * include/bits/vector.tcc (vector<bool, A>::_M_reallocate): Hoist loads of begin() and end() before allocation and use them to state an unreachable condition. * testsuite/23_containers/vector/bool/capacity/110498.cc: New test. Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
2025-03-31libstdc++: Fix -Wstringop-overread warning in std::vector<bool> [PR114758]Jonathan Wakely1-2/+3
As in r13-4393-gcca06f0d6d76b0 and a few other commits, we can avoid bogus warnings in std::vector<bool> by hoisting some loads to before the allocation that calls operator new. This means that the compiler has enough info to remove the dead branches that trigger bogus warnings. On trunk this is only needed with -fno-assume-sane-operators-new-delete but it will help on the branches where that option doesn't exist. libstdc++-v3/ChangeLog: PR libstdc++/114758 * include/bits/vector.tcc (vector<bool, A>::_M_fill_insert): Hoist loads of begin() and end() before allocation. * testsuite/23_containers/vector/bool/capacity/114758.cc: New test. Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
2025-03-31Libstdc++: Fix bootstrap failure for cross without tm.tm_zone [PR119550]Jonathan Wakely1-1/+1
In r15-8491-g778c28c70f8573 I added a use of the Autoconf macro AC_STRUCT_TIMEZONE, but that requires a link-test for the global tzname object if tm.tm_zone isn't supported. That link-test isn't allowed for cross-compilation, so bootstrap fails if tm.tm_zone isn't supported. Since libstdc++ only cares about tm.tm_zone and won't use tzname anyway, we don't need the link-test. Replace AC_STRUCT_TIMEZONE with a custom macro that only checks for tm.tm_zone. We can improve on the Autoconf macro by checking it's a suitable type, which isn't actually checked by AC_STRUCT_TIMEZONE. libstdc++-v3/ChangeLog: PR libstdc++/119550 * acinclude.m4 (GLIBCXX_STRUCT_TM_TM_ZONE): New macro. * config.h.in: Regenerate. * configure: Regenerate. * configure.ac: Use GLIBCXX_STRUCT_TM_TM_ZONE. * include/bits/chrono_io.h (__formatter_chrono::_M_c): Check _GLIBCXX_USE_STRUCT_TM_TM_ZONE instead of _GLIBCXX_HAVE_STRUCT_TM_TM_ZONE.
2025-03-31libstdc++: Constrain formatters for chrono types [PR119517]Tomasz Kamiński1-230/+218
The formatters for chrono types defined the parse/format methods as accepting unconstrained types, this in combination with lack of constrain on _CharT lead to them falsely satisfying formattable requirements for any type used as character. This patch adjust the fromatter<T, CharT>::parse signature to: constexpr typename basic_format_parse_context<_CharT>::iterator parse(basic_format_parse_context<_CharT>& __pc); And formatter<T, CharT>::format to: template<typename _Out> typename basic_format_context<_Out, _CharT>::iterator format(const T& __t, basic_format_context<_Out, _CharT>& __fc) const; Furthermore we _CharT with __format::__char (char or wchar_t), PR libstdc++/119517 libstdc++-v3/ChangeLog: * include/bits/chrono_io.h (formatter): Add __format::__char for _CharT and adjust parse and format method signatures. * testsuite/std/time/format/pr119517.cc: New test. Reviewed-by: Jonathan Wakely <jwakely@redhat.com> Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
2025-03-30Optimize string constructorJan Hubicka2-2/+33
this patch improves code generation on string constructors. We currently have _M_construct which takes as a parameter two iterators (begin/end pointers to other string) and produces new string. This patch adds special case of constructor where instead of begining/end pointers we readily know the string size and also special case when we know that source is 0 terminated. This happens commonly when producing stirng copies. Moreover currently ipa-prop is not able to propagate information that beg-end is known constant (copied string size) which makes it impossible for inliner to spot the common case where string size is known to be shorter than 15 bytes and fits in local buffer. Finally I made new constructor inline. Because it is explicitely instantiated without C++20 constexpr we do not produce implicit instantiation (as required by standard) which prevents inlining, ipa-modref and any other IPA analysis to happen. I think we need to make many of the other functions inline, since optimization accross string manipulation is quite important. There is PR94960 to track this issue. Bootstrapped/regtested x86_64-linux, OK? libstdc++-v3/ChangeLog: PR tree-optimization/103827 PR tree-optimization/80331 PR tree-optimization/87502 * config/abi/pre/gnu.ver: Add version for _M_construct<bool> * include/bits/basic_string.h: (basic_string::_M_construct<bool>): Declare. (basic_string constructors): Use it. * include/bits/basic_string.tcc: (basic_string::_M_construct<bool>): New template. * src/c++11/string-inst.cc: Instantated S::_M_construct<bool>. gcc/testsuite/ChangeLog: * g++.dg/tree-ssa/pr80331.C: New test. * g++.dg/tree-ssa/pr87502.C: New test.
2025-03-27libstdc++: Replace use of std::min in ranges::uninitialized_xxx algos [PR101587]Jonathan Wakely1-6/+26
Because ranges can have any signed integer-like type as difference_type, it's not valid to use std::min(diff1, diff2). Instead of calling std::min with an explicit template argument, this adds a new __mindist helper that determines the common type and uses that with std::min. libstdc++-v3/ChangeLog: PR libstdc++/101587 * include/bits/ranges_uninitialized.h (__detail::__mindist): New function object. (ranges::uninitialized_copy, ranges::uninitialized_copy_n) (ranges::uninitialized_move, ranges::uninitialized_move_n): Use __mindist instead of std::min. * testsuite/20_util/specialized_algorithms/uninitialized_copy/constrained.cc: Check ranges with difference difference types. * testsuite/20_util/specialized_algorithms/uninitialized_move/constrained.cc: Likewise.
2025-03-27libstdc++: Use const_cast to workaround tm_zone being non-constJonathan Wakely1-3/+4
Iain reported that he's seeing this on Darwin: include/bits/chrono_io.h:914: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings] This is because the BSD definition ot tm::tm_zone is a char* (and has been since 1987) rather than const char* as in Glibc and POSIX.1-2024. We can fix it by using const_cast<char*> when setting the tm_zone member. This should be safe because libc doesn't actually write anything to tm_zone; it's only non-const because the BSD definition predates the addition of the const keyword to C. For targets where it's a const char* the cast won't matter because it will be converted back to const char* on assignment anyway. libstdc++-v3/ChangeLog: * include/bits/chrono_io.h (__formatter_chrono::_M_c): Use const_cast when setting tm.tm_zone. Reviewed-by: Iain Sandoe <iain@sandoe.co.uk>
2025-03-27libstdc++: re-bump the feature-test macro for P2562R1 [PR119488]Giuseppe D'Angelo2-3/+3
Now that the algorithms have been merged we can advertise full support for P2562R1. This effectively reverts r15-8933-ga264c270fde292. libstdc++-v3/ChangeLog: PR libstdc++/119488 * include/bits/version.def (constexpr_algorithms): Bump the feature-testing macro. * include/bits/version.h: Regenerate. * testsuite/25_algorithms/cpp_lib_constexpr.cc: Test the bumped value for the feature-testing macro.
2025-03-27libstdc++: add constexpr stable_partitionGiuseppe D'Angelo3-2/+22
This completes the implementation of P2562R1 for C++26. Unlike the other constexpr algorithms of the same family, stable_partition does not have a constexpr-friendly version "ready to use" during constant evaluation. In fact, it is not even available on freestanding, because it always allocates a temporary memory buffer. This commit implements the simplest possible strategy: during constant evaluation allocate a buffer of length 1 on the stack, and use that as a working area. libstdc++-v3/ChangeLog: * include/bits/algorithmfwd.h (stable_partition): Mark it as constexpr for C++26. * include/bits/ranges_algo.h (__stable_partition_fn): Likewise. * include/bits/stl_algo.h (stable_partition): Mark it as constexpr for C++26; during constant evaluation use a new codepath where a temporary buffer of 1 element is used. * testsuite/25_algorithms/headers/algorithm/synopsis.cc (stable_partition): Add constexpr. * testsuite/25_algorithms/stable_partition/constexpr.cc: New test.
2025-03-27libstdc++: add constexpr inplace_mergeGiuseppe D'Angelo3-0/+13
This commit adds support for constexpr inplace_merge, added by P2562R1 for C++26. The implementation strategy is the same as for constexpr stable_sort: use if consteval to detect if we're in constant evaluation, and dispatch to a suitable path (same one as freestanding). libstdc++-v3/ChangeLog: * include/bits/algorithmfwd.h (inplace_merge): Mark it as constexpr for C++26. * include/bits/ranges_algo.h (__inplace_merge_fn): Likewise. * include/bits/stl_algo.h (inplace_merge): Mark it as constexpr; during constant evaluation, dispatch to the non-allocating codepath. * testsuite/25_algorithms/headers/algorithm/synopsis.cc (inplace_merge): Add constexpr. * testsuite/25_algorithms/inplace_merge/constexpr.cc: New test.
2025-03-27libstdc++: Fix std::ranges::iter_move for function references [PR119469]Jonathan Wakely1-2/+9
The result of std::move (or a cast to an rvalue reference) on a function reference is always an lvalue. Because std::ranges::iter_move was using the type std::remove_reference_t<X>&& as the result of std::move, it was giving the wrong type for function references. Use a decltype-specifier with declval<remove_reference_t<X>>() instead of just using the remove_reference_t<X>&& type directly. This gives the right result, while still avoiding the cost of doing overload resolution for std::move. libstdc++-v3/ChangeLog: PR libstdc++/119469 * include/bits/iterator_concepts.h (_IterMove::__result): Use decltype-specifier instead of an explicit type. * testsuite/24_iterators/customization_points/iter_move.cc: Check results for function references. Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
2025-03-26libstdc++: do not advertise full P2562R1 supportGiuseppe D'Angelo2-3/+3
P2562R1 ("constexpr Stable Sorting") adds constexpr to stable_sort, stable_partition and inplace_merge. However only the first is already implemented in libstdc++, so we shouldn't bump the feature-testing macro to the bumped C++26 value. This commit sets it to one less than the final value. Amends r15-7708-gff43f9853d3b10. libstdc++-v3/ChangeLog: * include/bits/version.def (constexpr_algorithms): Change the value of the feature-testing macro. * include/bits/version.h: Regenerate. * testsuite/25_algorithms/cpp_lib_constexpr.cc: Amend the check of the feature-testing macro.
2025-03-26libstdc++: Add P1206R7 range operations to std::deque [PR111055]Tomasz Kamiński2-31/+309
This is another piece of P1206R7, adding from_range constructor, append_range, prepend_range, insert_range, and assign_range members to std::deque. For append_front of input non-sized range, we are emplacing element at the front and then reverse inserted elements. This does not existing elements, and properly handle aliasing ranges. For insert_range, the handling of insertion in the middle of input-only ranges that are sized could be optimized, we still insert nodes one-by-one in such case. For forward and stronger ranges, we reduce them to common_range case, by computing the iterator when computing the distance. This is slightly suboptimal, as it require range to be iterated for non-common forward ranges that are sized, but reduces number of instantiations. This patch extract _M_range_prepend, _M_range_append helper functions that accepts (iterator, sentinel) pair. This all used in all standard modes. PR libstdc++/111055 libstdc++-v3/ChangeLog: * include/bits/deque.tcc (deque::prepend_range, deque::append_range) (deque::insert_range, __advance_dist): Define. (deque::_M_range_prepend, deque::_M_range_append): Extract from _M_range_insert_aux for _ForwardIterator(s). * include/bits/stl_deque.h (deque::assign_range): Define. (deque::prepend_range, deque::append_range, deque::insert_range): Declare. (deque(from_range_t, _Rg&&, const allocator_type&)): Define constructor and deduction guide. * include/debug/deque (deque::prepend_range, deque::append_range) (deque::assign_range): Define. (deque(from_range_t, _Rg&&, const allocator_type&)): Define constructor and deduction guide. * testsuite/23_containers/deque/cons/from_range.cc: New test. * testsuite/23_containers/deque/modifiers/append_range.cc: New test. * testsuite/23_containers/deque/modifiers/assign/assign_range.cc: New test. * testsuite/23_containers/deque/modifiers/prepend_range.cc: New test. Reviewed-by: Jonathan Wakely <jwakely@redhat.com> Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
2025-03-25libstdc++: Optimize std::vector construction from input iterators [PR108487]Jonathan Wakely1-16/+32
LWG 3291 make std::ranges::iota_view's iterator have input_iterator_tag as its iterator_category, even though it satisfies the C++20 std::forward_iterator concept. This means that the traditional std::vector::vector(InputIterator, InputIterator) constructor treats iota_view iterators as input iterators, because it only understands the C++17 iterator requirements, not the C++20 iterator concepts. This results in a loop that calls emplace_back for each individual element of the iota_view, requiring the vector to reallocate repeatedly as the values are inserted. This makes it unnecessarily slow to construct a vector from an iota_view. This change adds a new _M_range_initialize_n function for initializing a vector from a range (which doesn't have to be common) and a size. This new function can be used by vector(InputIterator, InputIterator) and vector(from_range_t, R&&) when std::ranges::distance can be used to get the size. It can also be used by the _M_range_initialize overload that gets the size for a Cpp17ForwardIterator pair using std::distance, and by the vector(initializer_list) constructor. With this new function constructing a std::vector from iota_view does a single allocation of the correct size and so doesn't need to reallocate in a loop. Previously the _M_range_initialize overload for Cpp17ForwardIterator was using a local RAII _Guard_alloc object to own the storage, but that was redundant. The _Vector_base can own the storage right away, and its destructor will deallocate it if _M_range_initialize exits via an exception. libstdc++-v3/ChangeLog: PR libstdc++/108487 * include/bits/stl_vector.h (vector(initializer_list)): Call _M_range_initialize_n instead of _M_range_initialize. (vector(InputIterator, InputIterator)): Use _M_range_initialize_n for C++20 sized sentinels and forward iterators. (vector(from_range_t, R&&)): Use _M_range_initialize_n for sized ranges and forward ranges. (vector::_M_range_initialize(FwIt, FwIt, forward_iterator_tag)): Likewise. (vector::_M_range_initialize_n): New function. * testsuite/23_containers/vector/cons/108487.cc: New test. Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
2025-03-25libstdc++: Fix std::vector::append_range for overlapping rangesJonathan Wakely3-20/+169
Unlike insert_range and assign_range, the append_range function does not have a precondition that the range doesn't overlap *this. That means we need to avoid relocating the existing elements until after copying from the range. This means I need to revert r15-8488-g3e1d760bf49d0e which made the from_range_t constructor use append_range, because the constructor can avoid the additional complexity needed by append_range. When relocating the existing elements in append_range we can use std::__relocate_a to do it more efficiently, if that's valid. std::vector<bool>::append_range needs similar treatment, although it's a bit simpler as we know that the elements are trivially copyable and so we don't need to worry about them throwing. assign_range doesn't allow overlapping ranges, so can be rewritten to be more efficient than calling append_range for the forward or sized range case. libstdc++-v3/ChangeLog: * include/bits/stl_bvector.h (vector::assign_range): More efficient implementation for forward/sized ranges. (vector::append_range): Handle potentially overlapping range. * include/bits/stl_vector.h (vector(from_range_t, R&&, Alloc)): Do not use append_range for non-sized input range case. (vector::append_range): Handle potentially overlapping range. * include/bits/vector.tcc (vector::insert_range): Forward range instead of moving it. * testsuite/23_containers/vector/bool/modifiers/insert/append_range.cc: Test overlapping ranges. * testsuite/23_containers/vector/modifiers/append_range.cc: Likewise. Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
2025-03-24libstdc++: Ensure that std::vector<bool> allocator has bool value_typeJonathan Wakely1-0/+4
This is the subject of LWG 4228 which notes that libstdc++ doesn't enforce this requirement. That's just a bug because I forgot to add it to vector<bool> when adding it elsewhere. For consistency with the other containers we should not allow incorrect allocator types for strict -std=c++NN modes, but it is very late to make that change for GCC 15 so this only enables the assertion for C++20 (where it's required). For GCC 16 we can enable it for strict modes too. libstdc++-v3/ChangeLog: * include/bits/stl_bvector.h (vector<bool, A>): Enforce the C++20 requirement that the allocator's value_type matches the container. * testsuite/23_containers/vector/bool/cons/from_range.cc: Fix incorrect allocator type. Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
2025-03-21libstdc++: Fix localized %c formatting for non-UTC times [PR117214]Jonathan Wakely1-1/+31
The previous commit fixed most cases of %c formatting, but it incorrectly prints times using the system's local time zone. This only matters if the locale's %c format includes %Z, but some do. To print a correct value for %Z we can set tm.tm_zone to either "UTC" or the abbreviation passed to the formatter in the local-time-format-t structure. For local times with no info and for systems that don't support tm_zone (which is new in POSIX.1-2024) we just set tm_isdst = -1 so that no zone name is printed. In theory, a locale's %c format could use %z which should print a +hhmm offset from UTC. I'm unsure how to control that though. The new tm_gmtoff field in combination with tm_isdst != -1 seems like it should work, but using that without also setting tm_zone causes the system zone to be used for %Z again. That means local_time_format(lt, nullptr, &off) might work for a locale that uses %z but prints the wrong thing for %Z. This commit doesn't set tm_gmtoff even if _M_offset_sec is provided for a local-time-format-t value. libstdc++-v3/ChangeLog: PR libstdc++/117214 * configure.ac: Use AC_STRUCT_TIMEZONE. * config.h.in: Regenerate. * configure: Regenerate. * include/bits/chrono_io.h (__formatter_chrono::_M_c): Set tm_isdst and tm_zone. * testsuite/std/time/format/pr117214.cc: Check %c formatting of zoned_time and local time.
2025-03-21libstdc++: Fix localized D_T_FMT %c formatting for <chrono> [PR117214]XU Kailiang1-16/+19
Formatting a time point with %c was implemented by calling std::vprint_to with format string constructed from locale's D_T_FMT string, but in some locales this string contains strftime specifiers which are not valid for chrono-specs, e.g. %l. So just use _M_locale_fmt to avoid this problem. libstdc++-v3/ChangeLog: PR libstdc++/117214 * include/bits/chrono_io.h (__formatter_chrono::_M_c): Use _M_locale_fmt to format %c time point. * testsuite/std/time/format/pr117214.cc: New test. Signed-off-by: XU Kailiang <xu2k3l4@outlook.com> Co-authored-by: Jonathan Wakely <jwakely@redhat.com>
2025-03-21libstdc++: Use formatting locale for std::time_put formatsJonathan Wakely1-0/+1
When using std::time_put to format a chrono value, we should imbue the formatting locale into the stream. This ensures that when std::time_put::do_put uses a ctype or __timepunct facet from the locale, it gets the correct facets. libstdc++-v3/ChangeLog: * include/bits/chrono_io.h (__formatter_chrono::_M_locale_fmt): Imbue locale into ostringstream. * testsuite/std/time/format/localized.cc: Check that correct locale is used for call to time_put::put. Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
2025-03-21libstdc++: Simplify std::vector::vector(from_range_t, const Alloc&)Jonathan Wakely1-18/+2
Tomasz suggested replacing this constructor with just append_range(rg), after using a delegating constructor so that the destructor will run if append_range exits via an exception. This is slightly less simple than his suggestion, because I want to avoid the overhead of reserve's slow path and the ASan annotations. Neither of those is needed for this constructor, because we have no existing storage to reallocate and no unused capacity to tell ASan about. libstdc++-v3/ChangeLog: * include/bits/stl_vector.h (vector(from_range_t, Alloc)): Use delegating constructor instead of RAII guards. Use append_range for unsized input range case. Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
2025-03-19libstdc++: Fix "IEE" typo in comment in std::time_put::do_putJonathan Wakely1-1/+1
libstdc++-v3/ChangeLog: * include/bits/locale_facets_nonio.tcc (time_put::do_put): Fix typo in comment.
2025-03-19libstdc++: Support maps deduction from_range of tuples.Tomasz Kamiński1-2/+8
This implements part of LWG4223 that enables deduction for maps types (map, unordered_map, flat_map and non-unique equivalent) from (from_range, rg, ...) arguments, where rg is range of tuple or other pair-like. libstdc++-v3/ChangeLog: * include/bits/ranges_base.h (__detail::__range_key_type): Replace RV::first_type with tuple_element_t<0, RV>. (__detail::__range_mapped_type) Replace RV::second_type with tuple_element_t<1, RV>. * testsuite/23_containers/flat_map/1.cc: New tests. * testsuite/23_containers/flat_multimap/1.cc: New tests. * testsuite/23_containers/map/cons/from_range.cc: New tests. * testsuite/23_containers/multimap/cons/from_range.cc: New tests. * testsuite/23_containers/unordered_map/cons/from_range.cc: New tests. * testsuite/23_containers/unordered_multimap/cons/from_range.cc: New tests. Reviewed-by: Jonathan Wakely <jwakely@redhat.com> Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
2025-03-19libstdc++-v3: Implement allocator-aware from_range_t constructors for ↵Tomasz Kamiński2-0/+29
unordered containers. This patch implements part of LWG2713 covering the from_range constructors, which makes std::ranges::to<std::unordered_set>(alloc) well-formed. Likewise for rest of unordered containers. As this consturctors were added to v15, this has no impact on code that compiled with previous versions. libstdc++-v3/ChangeLog: * include/bits/unordered_map.h (unordered_map(from_range_t, _Rg&&, const allocator_type&)) (unordered_multimap(from_range_t, _Rg&&, const allocator_type&)): Define. * include/bits/unordered_set.h (unordered_set(from_range_t, _Rg&&, const allocator_type&)) (unordered_multiset(from_range_t, _Rg&&, const allocator_type&)): Define. * testsuite/23_containers/unordered_map/cons/from_range.cc: New tests. New tests. * testsuite/23_containers/unordered_multimap/cons/from_range.cc: New tests. * testsuite/23_containers/unordered_multiset/cons/from_range.cc: New tests. * testsuite/23_containers/unordered_set/cons/from_range.cc: New tests. * testsuite/std/ranges/conv/1.cc: New tests. Reviewed-by: Jonathan Wakely <jwakely@redhat.com> Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
2025-03-19libstdc++: Cast difference_type for insert_range unordered non-unique ↵Tomasz Kamiński2-2/+2
containers [PR119358] ranges::distance may produce an integer-like class type (ranges::__detail::__max_diff_type) that is only explicitly convertible to other integer types, so the result needs to be casted to containers size_type. PR libstdc++/119358 libstdc++-v3/ChangeLog: * include/bits/unordered_map.h (unordered_multimap::insert_range): Cast ranges::distance to size_type before passing to _M_rehash_insert. * include/bits/unordered_set.h (unordered_multiset::insert_range): Same as unordered_multimap::insert_range. * testsuite/23_containers/unordered_multimap/cons/from_range.cc: New tests. * testsuite/23_containers/unordered_multiset/cons/from_range.cc: New tests.
2025-03-18libstdc++: Add P1206R7 from_range members to unordered maps [PR111055]Tomasz Kamiński1-0/+203
This is another piece of P1206R7, adding new members to std::unordered_map and std::unordered_multimap. PR libstdc++/111055 libstdc++-v3/ChangeLog: * include/bits/unordered_map.h (unordered_map): Define from_range constructors and insert_range member. (unordered_multimap): Likewise. * testsuite/23_containers/unordered_multimap/cons/from_range.cc: New test. * testsuite/23_containers/unordered_multimap/modifiers/insert_range.cc: New test. * testsuite/23_containers/unordered_map/cons/from_range.cc: New test. * testsuite/23_containers/unordered_map/modifiers/insert_range.cc: New test. Reviewed-by: Jonathan Wakely <jwakely@redhat.com> Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
2025-03-18libstdc++: Add P1206R7 from_range members to unordered sets [PR111055]Tomasz Kamiński2-16/+220
This is another piece of P1206R7, adding new members to std::unordered_set and std::unordered_multiset. PR libstdc++/111055 libstdc++-v3/ChangeLog: * include/bits/hashtable.h (_M_rehash_insert) (_M_insert_range_multi): Extracted rehashing for range insertion to separate function. * include/bits/unordered_set.h (unordered_set): Define from_range constructors and insert_range member. (unordered_multiset) Likewise. * testsuite/23_containers/unordered_multiset/cons/from_range.cc: New test. * testsuite/23_containers/unordered_multiset/modifiers/insert_range.cc: New test. * testsuite/23_containers/unordered_set/cons/from_range.cc: New test. * testsuite/23_containers/unordered_set/modifiers/insert_range.cc: New test. Reviewed-by: Jonathan Wakely <jwakely@redhat.com> Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
2025-03-18libstdc++: Add P1206R7 from_range members to ordered sets [PR111055]Tomasz Kamiński2-0/+107
This is another piece of P1206R7, adding new members to std::set and std::multiset. PR libstdc++/111055 libstdc++-v3/ChangeLog: * include/bits/stl_multiset.h: (inser_range) (multiset(from_range_t, _Rg&&, const _Compare&, const _Alloc&)) (multiset(from_range_t, _Rg&&, const _Alloc&)): Define. * include/bits/stl_set.h: (set(from_range_t, _Rg&&, const _Alloc&)) (set(from_range_t, _Rg&&, const _Compare&, const _Alloc&), insert_range): Define. * testsuite/23_containers/multiset/cons/from_range.cc: New test. * testsuite/23_containers/multiset/modifiers/insert/insert_range.cc: New test. * testsuite/23_containers/set/cons/from_range.cc: New test. * testsuite/23_containers/set/modifiers/insert/insert_range.cc: New test. Reviewed-by: Jonathan Wakely <jwakely@redhat.com> Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
2025-03-18libstdc++: Add P1206R7 from_range members to ordered maps [PR111055]Tomasz Kamiński3-0/+127
This is another piece of P1206R7, adding new members to std::map and std::multimap. PR libstdc++/111055 libstdc++-v3/ChangeLog: * include/bits/ranges_base.h (__detail::__range_to_alloc_type): Define. * include/bits/stl_multimap.h: (inser_range) (multimap(from_range_t, _Rg&&, const _Compare&, const _Alloc&)) (multimap(from_range_t, _Rg&&, const _Alloc&)): Define. * include/bits/stl_map.h: (map(from_range_t, _Rg&&, const _Alloc&)) i (map(from_range_t, _Rg&&, const _Compare&, const _Alloc&), insert_range): Define. * testsuite/23_containers/multimap/cons/from_range.cc: New test. * testsuite/23_containers/multimap/modifiers/insert/insert_range.cc: New test. * testsuite/23_containers/map/cons/from_range.cc: New test. * testsuite/23_containers/map/modifiers/insert/insert_range.cc: New test.
2025-03-14libstdc++: Missing 'constexpr' in vector's from_range ctor [PR119282]Patrick Palka1-1/+1
A missing 'constexpr' in the non-forward (and non-sized) branch of our recently implemented vector from_range ctor was causing this valid example to be rejected with a cryptic error. PR libstdc++/119282 libstdc++-v3/ChangeLog: * include/bits/stl_vector.h (vector::vector(from_range_t)): Add missing 'constexpr' to local class _Clear. * testsuite/std/ranges/conv/1.cc (test_pr119282): New test. Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
2025-03-14libstdc++: fix compile error when converting std::weak_ptr<T[]>Giuseppe D'Angelo1-1/+1
A std::weak_ptr<T[]> can be converted to a compatible std::weak_ptr<U[]>. This is implemented by having suitable converting constructors to std::weak_ptr which dispatch to the __weak_ptr base class (implementation detail). In __weak_ptr<T[]>, lock() is supposed to return a __shared_ptr<T[]>, not a __shared_ptr<element_type> (that is, __shared_ptr<T>). Unfortunately the return type of lock() and the type of the returned __shared_ptr were mismatching and that was causing a compile error: when converting a __weak_ptr<T[]> to a __weak_ptr<U[]> through __weak_ptr's converting constructor, the code calls lock(), and that simply fails to build. Fix it by removing the usage of element_type inside lock(), and using _Tp instead. Note that std::weak_ptr::lock() itself was already correct; the one in __weak_ptr was faulty (and that is the one called by __weak_ptr's converting constructors). libstdc++-v3/ChangeLog: * include/bits/shared_ptr_base.h (lock): Fixed a compile error when calling lock() on a weak_ptr<T[]>, by removing an erroneous usage of element_type from within lock(). * testsuite/20_util/shared_ptr/requirements/explicit_instantiation/1.cc: Add more tests for array types. * testsuite/20_util/weak_ptr/requirements/explicit_instantiation/1.cc: Likewise. * testsuite/20_util/shared_ptr/requirements/1.cc: New test. * testsuite/20_util/weak_ptr/requirements/1.cc: New test.
2025-03-13libstdc++: Add P1206R7 from_range members to container adaptors [PR111055]Jonathan Wakely2-0/+148
This is another piece of P1206R7, adding new members to std::stack, std::queue, and std::priority_queue. PR libstdc++/111055 libstdc++-v3/ChangeLog: * include/bits/stl_queue.h (queue(from_range_t, _Rg&&)) (queue(from_range_t, _Rg&&, const _Alloc&), push_range): Define. (priority_queue(from_range_t, R&&, const Compare&)) (push_range): Define. * include/bits/stl_stack.h (stack(from_range_t, R&&)) (stack(from_range_t, R&&, const Alloc&), push_range): Define. * testsuite/util/testsuite_iterators.h (test_range_nocopy): Define. * testsuite/23_containers/priority_queue/cons_from_range.cc: New test. * testsuite/23_containers/priority_queue/members/push_range.cc: New test. * testsuite/23_containers/queue/cons_from_range.cc: New test. * testsuite/23_containers/queue/members/push_range.cc: New test. * testsuite/23_containers/stack/cons_from_range.cc: New test. * testsuite/23_containers/stack/members/push_range.cc: New test. Co-authored-by: Tomasz Kamiński <tkaminsk@redhat.com> Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
2025-03-12libstdc++: Implement P3137R3 views::to_input for C++26Patrick Palka2-0/+18
libstdc++-v3/ChangeLog: * include/bits/version.def (ranges_to_input): Define. * include/bits/version.h: Regenerate. * include/std/ranges (ranges::to_input_view): Define for C++26. (views::__detail::__can_to_input): Likewise. (views::_ToInput, views::to_input): Likewise. * testsuite/std/ranges/adaptors/to_input/1.cc: New test. Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com> Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
2025-03-12libstdc++: Prevent dangling references in std::unique_ptr::operator*Jonathan Wakely1-0/+8
LWG 4148 (approved in Wrocław, November 2024) makes it ill-formed to dereference a std::unique_ptr if that would return a dangling reference. That can happen with a custom pointer type and a const-qualified element_type, such that std::add_lvalue_reference_t<element_type> is a reference-to-const that could bind to a short-lived temporary. In C++26 the compiler diagnoses this as an error anyway: bits/unique_ptr.h:457:16: error: returning reference to temporary [-Wreturn-local-addr] But that can be disabled with -Wno-return-local-addr so the static_assert ensures it is enforced consistently. libstdc++-v3/ChangeLog: * include/bits/unique_ptr.h (unique_ptr::operator*): Add static_assert to check for dangling reference, as per LWG 4148. * testsuite/20_util/unique_ptr/lwg4148.cc: New test. Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
2025-03-12libstdc++: Make range adaptor __has_arrow helper use a const typeJonathan Wakely1-1/+4
LWG 4112 (approved in Wrocław, November 2024) changes the has-arrow helper to require operator-> to be valid on a const-qualified lvalue. This affects the constraints for filter_view::_Iterator::operator-> and join_view::_Iterator::operator-> so that they can only be used if the underlying iterator supports operator-> on const. The change also adds semantic (i.e. not checkable and not enforced) requirements that operator-> must have the same semantics whether called on a const or non-const value, and on an lvalue or rvalue (due to the implicit expression variation rules in [concepts.equality]). libstdc++-v3/ChangeLog: * include/bits/ranges_util.h (ranges::_detail::__has_arrow): Require operator->() to be valid on const-qualified type, as per LWG 4112. * testsuite/std/ranges/adaptors/lwg4112.cc: New test. Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>