[Bug c++/115914] SIGSEGV when std::generator co_yield different ranges of elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115914 --- Comment #2 from 康桓瑋 --- (In reply to Andrew Pinski from comment #1) > I suspect this is a dup of bug 113460. Definitely.
[Bug c++/115914] New: SIGSEGV when std::generator co_yield different ranges of elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115914 Bug ID: 115914 Summary: SIGSEGV when std::generator co_yield different ranges of elements Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- #include #include #include #include template auto concat(Rs&&... rs) -> std::generator { (co_yield std::ranges::elements_of(rs), ...); } int main() { std::vector v{1, 2, 3}; auto r = std::views::iota(4, 10); for (int i : concat(v, r)) std::cout << i << ' '; } GCC emits SIGSEGV, while Clang outputs the expected results. https://godbolt.org/z/33h5TThea
[Bug libstdc++/115846] std::optional> is constant expression even in C++20 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115846 --- Comment #8 from 康桓瑋 --- (In reply to 康桓瑋 from comment #7) > (In reply to Jonathan Wakely from comment #6) > > (In reply to Andrew Pinski from comment #1) > > > I think it is due to: > > > include/std/optional: _GLIBCXX20_CONSTEXPR ~_Storage() { } > > > > > > Which was done in r12-4389-g476f305b6cf11d (for https://wg21.link/p2231 ). > > > > Yes, P2231 was approved as a DR against C++20, so std::optional has a > > constexpr destructor. > > > > The example works because no std::unique_ptr object needs to be destroyed, > > but it's not related to unique_ptr at all. It works for any type: > > > > Reduced: > > > > #include > > struct S { ~S() { } }; > > static_assert( not std::optional{} ); > > It seems like ~_Storage() doesn't call _M_value.~_Up(). > I could be wrong. [optional.dtor] specifies to call val->T::~T().
[Bug libstdc++/115846] std::optional> is constant expression even in C++20 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115846 --- Comment #7 from 康桓瑋 --- (In reply to Jonathan Wakely from comment #6) > (In reply to Andrew Pinski from comment #1) > > I think it is due to: > > include/std/optional: _GLIBCXX20_CONSTEXPR ~_Storage() { } > > > > Which was done in r12-4389-g476f305b6cf11d (for https://wg21.link/p2231 ). > > Yes, P2231 was approved as a DR against C++20, so std::optional has a > constexpr destructor. > > The example works because no std::unique_ptr object needs to be destroyed, > but it's not related to unique_ptr at all. It works for any type: > > Reduced: > > #include > struct S { ~S() { } }; > static_assert( not std::optional{} ); It seems like ~_Storage() doesn't call _M_value.~_Up(). I could be wrong.
[Bug libstdc++/115846] New: std::optional> is constant expression even in C++20 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115846 Bug ID: 115846 Summary: std::optional> is constant expression even in C++20 mode Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- #include #include // static_assert([] { // std::unique_ptr p; // non-constant condition for static assertion // return true; // }()); static_assert([] { std::optional> opt; return true; }()); GCC rejects the first but accepts the last, which seems wrong since unique_ptr's destructor is not constexpr in C++20. https://godbolt.org/z/38bToE8oE
[Bug libstdc++/115799] ranges::find's optimized branching for memchr is not quite right
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115799 --- Comment #8 from 康桓瑋 --- (In reply to Jonathan Wakely from comment #7) > Fixed now, thanks for the reports. Thanks for the quick fix. There may be another potential issue that I don't know if it is worth mentioning. When the difference_type of the contiguous_iterator is an integer-class type such as ranges::__detail::__max_diff_type, we may also need to perform an explicit conversion in the call of __builtin_memchr as the latter only accepts size_t.
[Bug c++/115814] New: class template argument deduction failed in C++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115814 Bug ID: 115814 Summary: class template argument deduction failed in C++20 Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- template struct overloaded : Ts... { }; // explicit deduction guide (not needed as of C++20) // template // overloaded(Ts...) -> overloaded; int main() { auto s = overloaded([]{}, []{}); } GCC rejects this, and changes (...) to {...} can work, but I think the above should be well-formed. https://godbolt.org/z/xah5fr8rn
[Bug libstdc++/115799] ranges::find's optimized branching for memchr is not quite right
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115799 --- Comment #3 from 康桓瑋 --- (In reply to Tamar Christina from comment #2) > I also get an ICE related: > > /opt/buildAgent/temp/buildTmp/toolchain/include/c++/15.0.0/bits/stl_algo.h: > 3873:38: error: no match for 'operator+' (operand types are > 'std::_Rb_tree_const_iterator' and 'long int') > 3873 | return __first + ((const char*)__p1 - (const > char*)__p0); > | > ^ Yes, it seems std:: version dies not check contiguous iterator.
[Bug c++/115803] New: ICE: tree check: expected class 'type', have 'constant' (integer_cst) in cp_type_quals, at cp/typeck.cc:11646
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115803 Bug ID: 115803 Summary: ICE: tree check: expected class 'type', have 'constant' (integer_cst) in cp_type_quals, at cp/typeck.cc:11646 Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- #include #include auto get_n = [](Tuple&& t, std::size_t index) { using variant_type = decltype(std::apply([](Ts...){ return std::variant{}; }, t)); return [&](std::index_sequence) { std::array fs = { +[](Tuple&& tup){ return variant_type{std::get(tup)};}... }; return fs[index](t); }(std::make_index_sequence<2>()); }; int main() { std::visit( [](auto&& v) { }, get_n(std::tuple{1,2.}, 1)); } https://godbolt.org/z/xYvoqfPeo
[Bug libstdc++/115799] New: ranges::find's optimized branching for memchr is not quite right
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115799 Bug ID: 115799 Summary: ranges::find's optimized branching for memchr is not quite right Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- ranges_util.h#L505: if constexpr (is_same_v<_Proj, identity>) if constexpr(__can_use_memchr_for_find, _Tp>) if constexpr (sized_sentinel_for<_Sent, _Iter>) if constexpr (contiguous_iterator<_Iter>) if (!is_constant_evaluated()) { if (static_cast>(__value) != __value) return __last; We should return __first + __n as __last may not be convertible to __first, for example: std::string s; auto r = std::ranges::find(std::counted_iterator{s.begin(), 3}, std::default_sentinel, ' ');
[Bug c++/115792] GCC accepts [] throw () {}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115792 --- Comment #7 from 康桓瑋 --- (In reply to Andrew Pinski from comment #6) > So I looked into the change for clang: > https://github.com/llvm/llvm-project/commit/ > 0620e6f4b76a9725dbd82454d58c5a68a7e47074 > > And they didn't add a testcase for throw(). Only noexcept. > > GCC add a testcase for `throw()` case though: > https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/testsuite/g%2B%2B.dg/cpp23/ > lambda-specifiers1.C;h=6729a4555ddd6c5a98771a71ee3b5bc9850c2bd7; > hb=0f161cc8494cf7283a16fa9ebbcf8fd121bab68d#l15 So you mean this is Clang bug?
[Bug c++/115792] New: GCC accepts [] throw () {}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115792 Bug ID: 115792 Summary: GCC accepts [] throw () {} Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- int main() { auto l = [] throw () {}; l(); } https://godbolt.org/z/GejGeKzjd Other compilers consider it a syntax error. I currently don't know who is right.
[Bug c++/115425] New: ICE: tree check: expected type_pack_expansion or expr_pack_expansion, have error_mark in tsubst_pack_expansion, at cp/pt.cc:13778
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115425 Bug ID: 115425 Summary: ICE: tree check: expected type_pack_expansion or expr_pack_expansion, have error_mark in tsubst_pack_expansion, at cp/pt.cc:13778 Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- This seems like 15 regressions and may related to the constexpr static local variable. https://godbolt.org/z/sf4f3Woqa #include template void foo(std::index_sequence); template struct S; template auto test() { using Seq = std::make_index_sequence>; constexpr static auto x = foo(); return [](std::index_sequence) { (typename S::type{}, ...); }(std::make_index_sequence<0>{}); } int main() { test>(); }
[Bug libstdc++/115218] New: The conversion constructor of concat_view::iterator always default-constructs variant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115218 Bug ID: 115218 Summary: The conversion constructor of concat_view::iterator always default-constructs variant Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- constexpr iterator(iterator __it) requires _Const && (convertible_to, iterator_t> && ...) : _M_parent(__it._M_parent) { _M_invoke_with_runtime_index([this, &__it]() { _M_it.template emplace<_Idx>(std::get<_Idx>(std::move(__it._M_it))); }); } This constructor always default-constructs variant which may not be well-formed: https://godbolt.org/z/YndEKGhz5 #include struct I { I() = delete; I(int*); using value_type = int; using difference_type = int; value_type& operator*() const; I& operator++(); void operator++(int); }; struct R { int* begin(); I begin() const; std::unreachable_sentinel_t end() const; }; int main() { auto c = std::ranges::concat_view{R{}}; const auto& cr = c; decltype(cr.begin()) it = c.begin(); // hard error }
[Bug libstdc++/115215] New: views::concat rejects non-movable references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115215 Bug ID: 115215 Summary: views::concat rejects non-movable references Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- libstdc++'s views::concat always requires concat_view(rs...) to be well-formed which does not fully conform with the wording as R does not need to satisfy concatable when there only one pack: #include #include int main() { auto r = std::views::iota(0, 5) | std::views::transform([](int) { return std::format_parse_context{""}; }); auto c = std::views::concat(r); // should be well-formed } https://godbolt.org/z/WG5TdsEce
[Bug libstdc++/115209] New: The implementation of concat_view refers to p2542r7 rather than the p2542r8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115209 Bug ID: 115209 Summary: The implementation of concat_view refers to p2542r7 rather than the p2542r8 Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- It seems that R8 is the final version. Not sure why libstdc++ refers to R7, which makes some updates of R8 not integrated, such as the new relaxed constraints of operator-(const iterator& x, default_sentinel_t).
[Bug libstdc++/115145] New: Help lambda in rewritten std::variant comparisons does not specify return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115145 Bug ID: 115145 Summary: Help lambda in rewritten std::variant comparisons does not specify return type Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- ..which can be an regression: #include struct Bool { operator bool(); Bool(const Bool&) = delete; }; struct Elem { Bool& operator==(const Elem&) const; }; int main() { std::variant v; return v == v; } https://godbolt.org/z/14q14TrYW
[Bug libstdc++/115098] std::vector::iterator::reference is default-constructible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115098 --- Comment #1 from 康桓瑋 --- std::bitset has similar issues: #include std::bitset<1> bitset; typename std::bitset<1>::reference bit_ref(bitset, 0); // well-formed in libstdc++ https://godbolt.org/z/T4qvv8TcG
[Bug libstdc++/115098] New: std::vector::iterator::reference is default-constructible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115098 Bug ID: 115098 Summary: std::vector::iterator::reference is default-constructible Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- ..which shouldn't because [vector.bool.pspc] specifies that its default constructor is private. #include typename std::vector::iterator::reference bit_ref; https://godbolt.org/z/WPxqWTjMY
[Bug c++/115067] New: Bogus -O2 -Wnull-dereference for istreambuf_iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115067 Bug ID: 115067 Summary: Bogus -O2 -Wnull-dereference for istreambuf_iterator Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- #include #include #include std::string fn() { std::istringstream is {"bob"}; auto beg = std::istreambuf_iterator(is); auto end = std::istreambuf_iterator(); return {beg, end}; } int main() { std::cout << fn() << "\n"; } https://godbolt.org/z/rGqW5he87 The above code always triggers the following warning when -O2 -Wnull-dereference is used since GCC-12: /opt/compiler-explorer/gcc-trunk-20240513/include/c++/15.0.0/streambuf:495:30: error: potential null pointer dereference [-Werror=null-dereference] 495 | egptr() const { return _M_in_end; } | ^ In member function 'std::basic_streambuf<_CharT, _Traits>::char_type* std::basic_streambuf<_CharT, _Traits>::gptr() const [with _CharT = char; _Traits = std::char_traits]', inlined from 'std::basic_streambuf<_CharT, _Traits>::int_type std::basic_streambuf<_CharT, _Traits>::sbumpc() [with _CharT = char; _Traits = std::char_traits]' at /opt/compiler-explorer/gcc-trunk-20240513/include/c++/15.0.0/streambuf:326:33, inlined from 'std::istreambuf_iterator<_CharT, _Traits>& std::istreambuf_iterator<_CharT, _Traits>::operator++() [with _CharT = char; _Traits = std::char_traits]' at /opt/compiler-explorer/gcc-trunk-20240513/include/c++/15.0.0/bits/streambuf_iterator.h:173:17, inlined from 'void std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::_M_construct(_InIterator, _InIterator, std::input_iterator_tag) [with _InIterator = std::istreambuf_iterator >; _CharT = char; _Traits = std::char_traits; _Alloc = std::allocator]' at /opt/compiler-explorer/gcc-trunk-20240513/include/c++/15.0.0/bits/basic_string.tcc:182:6, inlined from 'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string(_InputIterator, _InputIterator, const _Alloc&) [with _InputIterator = std::istreambuf_iterator >; = void; _CharT = char; _Traits = std::char_traits; _Alloc = std::allocator]' at /opt/compiler-explorer/gcc-trunk-20240513/include/c++/15.0.0/bits/basic_string.h:770:16, inlined from 'std::string fn()' at :9:19: /opt/compiler-explorer/gcc-trunk-20240513/include/c++/15.0.0/streambuf:492:30: error: potential null pointer dereference [-Werror=null-dereference] 492 | gptr() const { return _M_in_cur; }
[Bug libstdc++/115046] meta-recursion when apply join_view with as_const_view
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115046 --- Comment #1 from 康桓瑋 --- Oh, maybe this is just because MSVC does not use std::optional but uses _Defaultabox.
[Bug libstdc++/115046] New: meta-recursion when apply join_view with as_const_view
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115046 Bug ID: 115046 Summary: meta-recursion when apply join_view with as_const_view Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- I seriously doubt this is a more practical example of LWG 3986 since join_view has a std::optional member to store the iterator, but I'm not sure about whether this is a language bug or a library bug since MSVC doesn't have the issue: #include #include int main() { std::list l; auto r = l | std::views::chunk(3) | std::views::transform(std::views::as_const) | std::views::join; for (auto&& elem : r) { // infinite meta-recursion } } https://godbolt.org/z/Morx4voT8 Reduction is a nightmare, so I only do it when I have time.
[Bug libstdc++/115045] New: views::adjacent_transform<0> is underconstrained
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115045 Bug ID: 115045 Summary: views::adjacent_transform<0> is underconstrained Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- This is related to the PR38. #include int main() { std::views::adjacent_transform<0>(std::views::single(0), []{}); // hard error in libstdc++ }
[Bug c++/115000] New: Confusing 'cannot convert to 'int' in initialization' error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115000 Bug ID: 115000 Summary: Confusing 'cannot convert to 'int' in initialization' error message Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- Consider the following: #include struct S { S() = default; S(S&&) = default; }; S s; std::ranges::single_view r{s}; https://godbolt.org/z/65nvdaTfP GCC reports constraints not satisfied which is correct, however, there is more: :9:31: error: cannot convert 'S' to 'int' in initialization 9 | std::ranges::single_view r{s}; | ^ | | | S This is confusing since there is nothing to do with 'int'.
[Bug c++/114934] New: Error message for expected unqualified-id could be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114934 Bug ID: 114934 Summary: Error message for expected unqualified-id could be improved Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- Suppose I misspelled an extra colon for the namespace (https://godbolt.org/z/q3b7531q3): #include #include using Tuple = std::tuple; GCC gives: :4:43: error: template argument 1 is invalid 4 | using Tuple = std::tuple; | ^ Although it is not stated why it is invalid, it is still acceptable. Clang gives: :4:31: error: expected unqualified-id 4 | using Tuple = std::tuple; | ^ It correctly points out the location of the issue which is nice. However, I changed it to the following (https://godbolt.org/z/zfoqeoxE3): #include #include using Pair = std::pair; GCC will give: :4:41: error: wrong number of template arguments (1, should be 2) 4 | using Pair = std::pair; | This is unkind because it doesn't indicate which one is invalid, but rather the *wrong number* of arguments. This can be very confusing to users who haven't discovered the typo, as there are indeed 2 template parameters here (which can make debugging extremely difficult if there are plenty of template parameters in the template list)
[Bug c++/114845] New: Confusing message when using undeclared identifier of Const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114845 Bug ID: 114845 Summary: Confusing message when using undeclared identifier of Const Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- https://godbolt.org/z/v6M35zMa4 There is a typo here, I missed an underscore: template requires Const_ struct S; S s; The error message reported by Clang is: :1:33: error: use of undeclared identifier 'Const_'; did you mean 'Const__'? 1 | template requires Const_ | ^~ | Const__ which is clear and corrects my typo. However, the error given by GCC is: :4:7: error: 'Const_' was not declared in this scope; did you mean 'const'? 4 | S s; | ^ | const First, the cursor points to 'S s', and there is no identifier name 'Const_' here. Second, in context, I definitely do not mean the keyword 'const' because 'requires const' makes no sense.
[Bug libstdc++/103924] views::join combined with std::string cannot be used in constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103924 --- Comment #4 from 康桓瑋 --- (In reply to Patrick Palka from comment #2) > *** Bug 114530 has been marked as a duplicate of this bug. *** That's my lost memory.
[Bug libstdc++/114530] New: accessing 'std::__cxx11::basic_string::::_M_allocated_capacity' member instead of initialized 'std::__cxx11::basic_string::::_M_lo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114530 Bug ID: 114530 Summary: accessing 'std::__cxx11::basic_string_M_allocated_capacity' member instead of initialized 'std::__cxx11::basic_string_M_local_buf' member in constant expression Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- GCC rejects the following: #include #include static_assert( std::ranges::distance( std::views::single(std::views::cartesian_product(std::string{})) | std::views::join ) == 0 ); https://godbolt.org/z/4xcYxsMW4 The above seems to be a valid constant expression. It is worth noting that replacing std::string{} with std::vector{} compiles fine, see https://godbolt.org/z/bKdexfzcz It's unclear whether this is a library bug or a language bug.
[Bug libstdc++/114477] The user-defined constructor of filter_view::iterator is not fully compliant with the standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114477 --- Comment #6 from 康桓瑋 --- (In reply to Jiang An from comment #5) > (In reply to 康桓瑋 from comment #0) > > Since P3059R0 is closed (although I feel bad about this) > > BTW, now I think this is somehow unfortunate. > P3059 behaved like a follow-up paper of P2711 IMO. Both papers effectively > suggested that "some design choices of C++23 views are better, let's apply > them to C++20 views". You are absolutely right. Is there any way to reopen it? I recall that it was just because the committee didn't want to spend time on it.
[Bug libstdc++/114477] New: The user-defined constructor of filter_view::iterator is not fully compliant with the standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114477 Bug ID: 114477 Summary: The user-defined constructor of filter_view::iterator is not fully compliant with the standard Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- Since P3059R0 is closed (although I feel bad about this), this suggests that libstdc++ may need to modify the user-defined constructor of filter_view::iterator: #include auto base = std::views::iota(0); auto filter = base | std::views::filter([](int) { return true; }); auto begin = decltype(filter.begin())(filter, base.begin()); // should ok https://godbolt.org/z/T7nY68rej
[Bug c++/113929] New: GCC accepts template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113929 Bug ID: 113929 Summary: GCC accepts template Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- This is the sibling of Bug 113788. template struct S {} ; S<0> s{}; https://godbolt.org/z/GbdqW9zee Thank you.
[Bug c++/113810] New: A lambda with this auto style that captures this in a member function cannot use this pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113810 Bug ID: 113810 Summary: A lambda with this auto style that captures this in a member function cannot use this pointer Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- struct S { int i = 42; constexpr auto f() { return [this](this auto) { return this->i; }(); }; }; int main() { return S().f(); } https://godbolt.org/z/rMqaT9r9E GCC rejects the above with: :5:14: error: invalid use of 'this' in non-member function 5 | return this->i; | ^~~~ But lambda captures this pointer so it should be usable.
[Bug c++/113802] New: gcc rejects auto f(this auto self...) { }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113802 Bug ID: 113802 Summary: gcc rejects auto f(this auto self...) { } Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- struct S { auto f(this auto self...) { } }; int main() { S{}.f(); } https://godbolt.org/z/a81WPW65f GCC rejects the above code with: :2:10: error: an explicit object parameter cannot be a function parameter pack 2 | auto f(this auto self...) { } | ^~ But there is no parameter pack here, this should be a variadic function (I think?) Only `auto f(this auto...) { }` has parameter pack.
[Bug c++/113788] New: Deducing this is broken with structured binding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113788 Bug ID: 113788 Summary: Deducing this is broken with structured binding Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- GCC accepts the following: struct S { int a, b; }; int main() { S s = {1, 2}; this auto& [a, b] = s; return b; } Thanks. https://godbolt.org/z/34xTee6sx
[Bug c++/113640] 'deducing this' lambda invoked multiple times unexpectedly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113640 --- Comment #1 from 康桓瑋 --- Noted that changing `this auto self` to `this auto&& self` will get the expected results
[Bug c++/113640] New: 'deducing this' lambda invoked multiple times unexpectedly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113640 Bug ID: 113640 Summary: 'deducing this' lambda invoked multiple times unexpectedly Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- #include int main() { auto l = [](this auto self, int n) { std::cout << n << " "; return self; }; l(1)(42)(100); } https://godbolt.org/z/3rEoGsPWe Clang prints "1 42 100" as expected, however, GCC prints "1 1 42 1 42 100", which is weird.
[Bug c++/113629] 'deducing this' does not work with conversion operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113629 --- Comment #2 from 康桓瑋 --- more reduced: struct Base { operator int(this auto&&) { return 42; } }; int main() { Base b; // return static_cast(Base{}); // ok return static_cast(b); // error } https://godbolt.org/z/qGrbf4rj7
[Bug c++/113629] 'deducing this' does not work with conversion operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113629 --- Comment #1 from 康桓瑋 --- test: https://godbolt.org/z/jdz3ejohv
[Bug c++/113629] New: 'deducing this' does not work with conversion operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113629 Bug ID: 113629 Summary: 'deducing this' does not work with conversion operators Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- It seems that GCC's deducing this implementation has some issues with derived classes that inherit from a base class that has conversion operators: struct Base { operator int(this auto&&) { return 42; } }; struct Derived : Base {}; int main() { Derived derived; return static_cast(derived); } GCC rejects the above code with: :11:10: error: invalid 'static_cast' from type 'Derived' to type 'int' 11 | return static_cast(derived); | ^ which seems wrong.
[Bug c++/113595] New: Confusing 'goto' is not a constant expression error message in constructor at compile time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113595 Bug ID: 113595 Summary: Confusing 'goto' is not a constant expression error message in constructor at compile time Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- template struct MyArr { constexpr MyArr(const int ()[N]) { for (int i = 0; i < N; i++) arr_[i] = arr[i]; } int arr_[N]; }; constexpr int arr[10] = {}; constexpr MyArr<10> my_arr(arr); https://godbolt.org/z/978rTjqGP --- GCC correctly (I think) rejects the above code, but the error message is a bit confusing: :4:5: error: 'goto' is not a constant expression 4 | for (int i = 0; i < N; i++) | ^~~ since there is no 'goto' in the code.
[Bug libstdc++/113320] New: libstdc++ accepts std::format(std::move(runtime_fmt), 42);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113320 Bug ID: 113320 Summary: libstdc++ accepts std::format(std::move(runtime_fmt), 42); Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- The new constructor of libstdc++'s basic_format_string accepts an rvalue reference to a runtime-format-string instead of a value, which makes the following incorrectly accepted: #include int main() { auto runtime_fmt = std::runtime_format("{}"); auto str = std::format(std::move(runtime_fmt), 42); // should error } https://godbolt.org/z/zjW7shba1
[Bug libstdc++/113068] : ranges::to() | ranges::to() is not a range adaptor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113068 --- Comment #2 from 康桓瑋 --- (In reply to Patrick Palka from comment #1) > IIUC this will be fixed by making ranges::to's closure object > SFINAE-friendly. I didn't investigate the root cause in depth. So this should probably be considered a duplicate of PR 112802, right?
[Bug libstdc++/113068] New: : ranges::to() | ranges::to() is not a range adaptor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113068 Bug ID: 113068 Summary: : ranges::to() | ranges::to() is not a range adaptor Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- libstdc++ rejects the following code, which it shouldn't be. #include #include int main() { auto adaptor = std::ranges::to() | std::ranges::to(); auto str = adaptor(" "); } https://godbolt.org/z/7TrzcdTcz
[Bug libstdc++/113055] New: possibly-const-range missing constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113055 Bug ID: 113055 Summary: possibly-const-range missing constraints Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- ranges_base.h#L628: template constexpr auto& __possibly_const_range(_Range& __r) noexcept { if constexpr (constant_range && !constant_range<_Range>) return const_cast(__r); else return __r; } But according to the current wording, _Range must satisfy input_range, which means the following should not be accepted: #include #include int main() { std::vector v; auto r = std::views::counted(std::back_inserter(v), 3); auto ce = std::ranges::cend(r); } https://godbolt.org/z/Wa4Y3fPa6 Although I tried to submit LWG 3768, but it was rejected.
[Bug libstdc++/112876] ranges:to: c.end() is unnecessarily assigned by the return value of c.emplace()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112876 --- Comment #7 from 康桓瑋 --- (In reply to Jonathan Wakely from comment #6) > Fixed, thanks again for catching this divergence from the wording. Although the status of this LWG 4016 has not been updated on github, I can assume that it has been accepted by LWG, right? In addition, I would like to mention that `using _RefT = range_reference_t<_Rg>;` in ranges#L9286 can be removed because there is no place to use it.
[Bug libstdc++/112876] ranges:to: c.end() is unnecessarily assigned by the return value of c.emplace()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112876 --- Comment #2 from 康桓瑋 --- I believe the above is well-formed after LWG 4016. In addition, container-appendable requires `c.emplace(c.end(), *it)` to be well-formed but `auto end = c.end(); c.emplace(end, *it);` may not be. Sorry for the pedantic.
[Bug libstdc++/112876] ranges:to: c.end() is unnecessarily assigned by the return value of c.emplace()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112876 康桓瑋 changed: What|Removed |Added Summary|rangesc.end() is|ranges:to: c.end() is |unnecessarily assigned by |unnecessarily assigned by |the return value of |the return value of |c.emplace() |c.emplace() --- Comment #1 from 康桓瑋 --- which is not guaranteed to be well-formed. #include struct R { std::string insert(int, int); int end(); }; auto r = std::ranges::to(std::views::single(0));
[Bug libstdc++/112876] New: rangesc.end() is unnecessarily assigned by the return value of c.emplace()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112876 Bug ID: 112876 Summary: rangesc.end() is unnecessarily assigned by the return value of c.emplace() Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: ---
[Bug libstdc++/105118] Why is unexpected::value() named error() in libstdc++?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105118 康桓瑋 changed: What|Removed |Added Resolution|--- |INVALID Status|SUSPENDED |RESOLVED --- Comment #3 from 康桓瑋 --- Closed as P2549 was approved in C++23.
[Bug libstdc++/112803] New: : to(Args&&... args) is missing Mandates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112803 Bug ID: 112803 Summary: : to(Args&&... args) is missing Mandates Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- [range.utility.conv.adaptors]: Mandates: For the first overload, C is a cv-unqualified class type. https://godbolt.org/z/zxjhGx4re #include auto r = std::ranges::to();
[Bug libstdc++/112802] New: : _ToClosure::operator() has no constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112802 Bug ID: 112802 Summary: : _ToClosure::operator() has no constraints Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- which means this is not SFINAE-friendly. That's not standard compliance, right? #include #include template concept test = requires { std::ranges::to>()(T{}); }; static_assert(!test); // hard error in libstdc++ https://godbolt.org/z/Tasba18Kv
[Bug libstdc++/112641] New: : `drop_view::begin const` has ????(n) complexity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112641 Bug ID: 112641 Summary: : `drop_view::begin const` has (n) complexity Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- The wording of `drop_view::begin const` in [range.drop.view] is Returns: ranges::next(ranges::begin(base_), count_, ranges::end(base_)). Note that "returns" is used here, which means that the implementation only needs to return the value of `ranges::next` and does not need to obtain the value through `ranges::advance`, which will have 풪(n) complexity in the case of random-access-sized but non-common range. #include int main() { const auto s = std::ranges::subrange(std::views::iota(0uz), size_t(-1)); const auto r = std::ranges::drop_view(s, s.size() - 1); const auto b = r.begin(); // time out } https://godbolt.org/z/1KnKKacs8 Thanks to Mr. Jonathan for clarifying this on the LWG mailing list.
[Bug libstdc++/112607] New: : _Normalize does not consider char_type for the basic_string_view case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112607 Bug ID: 112607 Summary: : _Normalize does not consider char_type for the basic_string_view case Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- When T in basic_format_arg(T& v) is a specialization of basic_string_view or basic_string, format#arg-6.8 indicates: otherwise, if TD is a specialization of basic_string_view or basic_string and TD::value_type is char_type, initializes value with basic_string_view(v.data(), v.size()); We need to consider TD::value_type is char_type. However, libstd++ only uses __is_specialization_of to detect whether T is a specialization of basic_string_view or basic_string (format#L3118-L3121): else if constexpr (__is_specialization_of<_Td, basic_string_view>) return type_identity>(); else if constexpr (__is_specialization_of<_Td, basic_string>) return type_identity>(); This causes basic_format_arg to incorrectly use wstring_view to initialize string_view when customizing std::wstring. https://godbolt.org/z/6Kd16z8qK #include template<> struct std::formatter : std::formatter { auto format(const std::wstring& obj, auto& ctx) const { return std::formatter::format(" ", ctx); } }; int main(){ std::wstring wstr; std::string str = std::format("{}", wstr); }
[Bug c++/112490] New: infinite meta error in reverse_iterator::iterator>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112490 Bug ID: 112490 Summary: infinite meta error in reverse_iterator::ite rator>> Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- #include #include using I = std::vector::iterator; using CI = std::basic_const_iterator; using RCI = std::reverse_iterator; static_assert(std::totally_ordered); https://godbolt.org/z/14zsETc4d The fact that libc++ does not generate an error suggests that this may be a language bug. Not sure where the real issue here, I will reduce it when I have time.
[Bug libstdc++/112473] New: integer_sequence accepts non-integer types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112473 Bug ID: 112473 Summary: integer_sequence accepts non-integer types Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- >From [intseq.intseq]: Mandates: T is an integer type. testcase: #include int main() { std::integer_sequence, std::pair{0, 0}> ic; } https://godbolt.org/z/j9h7Yr1YM
[Bug libstdc++/112453] New: : __take_of_repeat_view/__drop_of_repeat_view should forwards __r._M_value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112453 Bug ID: 112453 Summary: : __take_of_repeat_view/__drop_of_repeat_view should forwards __r._M_value Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- The current wording clearly indicates *E.value_ instead of *r.value_. https://godbolt.org/z/GcnbesbEE #include #include int main() { auto t = std::views::repeat(std::make_unique(5), 4) | std::views::take(2); auto d = std::views::repeat(std::make_unique(5), 4) | std::views::drop(2); }
[Bug libstdc++/112452] New: : operator|(_Range&& __r, _Self&& __self) should return decltype(auto)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112452 Bug ID: 112452 Summary: : operator|(_Range&& __r, _Self&& __self) should return decltype(auto) Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- The is the same issue with https://github.com/microsoft/STL/issues/4153.
[Bug libstdc++/112349] ranges::max makes unnecessary copies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112349 康桓瑋 changed: What|Removed |Added CC||hewillk at gmail dot com --- Comment #2 from 康桓瑋 --- (In reply to Jonathan Wakely from comment #1) > > I think that would be OK too. > > auto __result = *__first; > while (++__first != __last) > { > if (std::__invoke(__comp, > std::__invoke(__proj, __result), > std::__invoke(__proj, *__first))) > __result = *__first; > } > return __result; `auto __result = *__first;` may not be OK, `range_value_t<_Range> __result(*__first);` is OK.
[Bug libstdc++/111948] subrange modifies a const size object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111948 --- Comment #5 from 康桓瑋 --- It shouldn't be. Is that a compiler bug? Clang compiles the same libstdc++ code without problems.(In reply to Jonathan Wakely from comment #2) > (In reply to 康桓瑋 from comment #1) > > _M_size._M_size in the function body is already const. > > It shouldn't be. Is that a compiler bug? > > Clang compiles the same libstdc++ code without problems. Sorry, I didn't delve into whether this was a bug in libstdc++ or the compiler. At the moment it seems this is a compiler problem. https://godbolt.org/z/ronn4exhG
[Bug libstdc++/111948] subrange modifies a const size object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111948 --- Comment #1 from 康桓瑋 --- This is the cause: constexpr subrange(__detail::__convertible_to_non_slicing<_It> auto __i, _Sent __s, __size_type __n) noexcept(is_nothrow_constructible_v<_It, decltype(__i)> && is_nothrow_constructible_v<_Sent, _Sent&>) requires (_Kind == subrange_kind::sized) : _M_begin(std::move(__i)), _M_end(__s) { if constexpr (_S_store_size) _M_size._M_size = __n; } _M_size._M_size in the function body is already const.
[Bug libstdc++/111948] New: subrange modifies a const size object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111948 Bug ID: 111948 Summary: subrange modifies a const size object Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- https://godbolt.org/z/Gf4zWP3qT testcase: #include constexpr auto r = std::ranges::subrange(std::views::iota(0), 5); static_assert(std::ranges::distance(r));
[Bug libstdc++/111861] New: ranges::min/max should not use `auto __result = *__first;`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111861 Bug ID: 111861 Summary: ranges::min/max should not use `auto __result = *__first;` Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- The constraints on the function signature do not guarantee that constructible_from>, iter_reference_t> is true. The same goes for unique_copy's input_range branch. Contrived testcase: https://godbolt.org/z/Kannq6Yo9
[Bug c++/111717] syntax error When CTAD encounters complex alias template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111717 --- Comment #1 from 康桓瑋 --- #include namespace std { constexpr size_t dynamic_extent = -1; template class extents { }; template using dextents = decltype([](index_sequence) { return extents{}; }(make_index_sequence{})); // this works well static_assert(std::is_same_v< dextents, extents> ); template class mdspan { template explicit mdspan(Ptr ptr, Integrals... exts); }; template explicit mdspan(ElementType*, Integrals...) ->mdspan>; } https://godbolt.org/z/E45dcb4G8
[Bug c++/111717] New: syntax error When CTAD encounters complex alias template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111717 Bug ID: 111717 Summary: syntax error When CTAD encounters complex alias template Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: ---
[Bug libstdc++/111713] libstdc++ accepts invalid regular expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111713 --- Comment #1 from 康桓瑋 --- The "+*" part is not valid.
[Bug libstdc++/111713] New: libstdc++ accepts regular expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111713 Bug ID: 111713 Summary: libstdc++ accepts regular expression Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- #include #include #include int main() { std::regex invalid_re("AAA\\s*(\\w+*)"); // should throw std::smatch match; std::string str("AAA BBB"); assert(std::regex_match(str, match, invalid_re)); std::cout << match[1] << "\n"; // libstdc++ prints BBB } https://godbolt.org/z/1zrv1Wf71
[Bug c++/111712] New: Syntax error when passing function parameter as NTTP in requires-clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111712 Bug ID: 111712 Summary: Syntax error when passing function parameter as NTTP in requires-clause Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- Regardless of whether the code is well-formed or not, this should be valid syntax https://godbolt.org/z/4qM9nG4WP #include template void f(std::bool_constant b) requires requires { typename std::bool_constant; }; int main() { f(std::true_type{}); } However, GCC givs :5:54: error: template argument 1 is invalid :5:37: error: invalid use of template-name 'std::bool_constant' without an argument list 5 | requires requires { typename std::bool_constant; }; | ^ In file included from :1: /opt/compiler-explorer/gcc-trunk-20231005/include/c++/14.0.0/type_traits:120:11: note: 'template using std::bool_constant = std::__bool_constant<__v>' declared here 120 | using bool_constant = __bool_constant<__v>; | ^ :5:50: error: expected '(' before '<' token 5 | requires requires { typename std::bool_constant; }; | ^ | ( :5:55: error: expected primary-expression before ';' token 5 | requires requires { typename std::bool_constant; }; | ^
[Bug libstdc++/111568] std::not_fn can accept non-movable function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111568 --- Comment #1 from 康桓瑋 --- bind_front also seems to missing Mandates: https://godbolt.org/z/8WPxc44h6 #include struct OnlyMovableFun { OnlyMovableFun() = default; OnlyMovableFun(const OnlyMovableFun&) = delete; OnlyMovableFun(OnlyMovableFun&&) = default; bool operator()(auto) const; }; int main() { OnlyMovableFun f; auto nf = std::bind_front(f); // should be static_assert? }
[Bug libstdc++/111550] The range adaptor closure object generated by adaptor(args...) is not a perfect forwarding call wrapper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111550 --- Comment #3 from 康桓瑋 --- Let me report another issue I observed on this PR. According to [range.adaptor.object], adaptor(args...) uses std::forward(args).. . to forward arguments into the call wrapper's decayed member, whereas libstdc++ unconditionally uses std::moves, which causes the following code to be rejected: https://godbolt.org/z/EYoxzfWKn #include struct NonMovable { NonMovable() = default; NonMovable(const NonMovable&) = default; NonMovable(NonMovable&&) = delete; }; int main() { NonMovable nonmovable; auto r = std::views::take(nonmovable); // hard error in libc++ and lidstdc++ } The libc++ implementation uses std::bind_back, so it will also produce a hard error because std::bind_back requires that the argument must be move-constructible. It seems like only MSVC conforms to the standard's wording. The standard does not require the type of args... here to be move-constructible like other call wrapper factories (such as std::bind_front/std::bind_back/std::bind) do, which seems to introduce some inconsistencies. Although I don't think such constraint is necessary, and I don't know if it's worthy of an LWG?
[Bug libstdc++/111568] New: std::not_fn can accept non-movable function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111568 Bug ID: 111568 Summary: std::not_fn can accept non-movable function Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- It seems that std::not_fn should reject the following code according to [func.not.fn]: "Mandates: is_constructible_v && is_move_constructible_v is true." https://godbolt.org/z/MsrqnbY74 #include struct OnlyCopyableFun { OnlyCopyableFun() = default; OnlyCopyableFun(const OnlyCopyableFun&) = default; OnlyCopyableFun(OnlyCopyableFun&&) = delete; bool operator()(auto) const; }; int main() { OnlyCopyableFun f; auto nf = std::not_fn(f); // only ill-formed in libc++ } Not quite sure why these standard call wrapper factories (std::bind_front, std::bind, etc.) require all argument types to be move-constructible, although the call wrapper produced in the above example is still move-constructible as its underlying type has a copy constructor. It seems to me that just requiring is_constructible_v is enough, which is what the range adaptor object does.
[Bug libstdc++/111550] The range adaptor closure object generated by adaptor(args...) is not a perfect forwarding call wrapper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111550 --- Comment #2 from 康桓瑋 --- (In reply to Jonathan Wakely from comment #1) > I think all four bugs related to adaptor closures are very similar and could > be a single bug report. Perhaps. Maybe I should collect them all. Sorry for bringing up bits and pieces.
[Bug libstdc++/111550] New: The range adaptor closure object generated by adaptor(args...) is not a perfect forwarding call wrapper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111550 Bug ID: 111550 Summary: The range adaptor closure object generated by adaptor(args...) is not a perfect forwarding call wrapper Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- The call operator of _Partial only handles the const& and && qualifiers, which is missing the & and const&& and causes the following code to be rejected. #include struct Five { operator int() &; operator int() && = delete; }; int main() { auto take_five = std::views::take(Five{}); auto r = take_five(std::views::iota(0)); } https://godbolt.org/z/b19fsGceG
[Bug libstdc++/111549] New: _RangeAdaptorClosure's (adaptor | adaptor) operator is underconstrained
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111549 Bug ID: 111549 Summary: _RangeAdaptorClosure's (adaptor | adaptor) operator is underconstrained Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- // Compose the adaptors __lhs and __rhs into a pipeline, returning // another range adaptor closure object. template requires __is_range_adaptor_closure<_Lhs> && __is_range_adaptor_closure<_Rhs> constexpr auto operator|(_Lhs __lhs, _Rhs __rhs) { return _Pipe<_Lhs, _Rhs>{std::move(__lhs), std::move(__rhs)}; } User-defined range adapter closure is not necessarily movable, in which case we may need to constrain the pipe operator to avoid hard errors inside the function. #include struct Closure : std::ranges::range_adaptor_closure { Closure() = default; Closure(Closure&&) = delete; auto operator()(std::ranges::range auto&&) const; }; int main() { auto r = std::views::take(5) | Closure{}; } https://godbolt.org/z/eqdvxxh3r
[Bug c++/111539] New: __is_range_adaptor_closure_fn is too loosely defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111539 Bug ID: 111539 Summary: __is_range_adaptor_closure_fn is too loosely defined Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- template requires (!same_as<_Tp, _RangeAdaptorClosure<_Up>>) void __is_range_adaptor_closure_fn (const _Tp&, const _RangeAdaptorClosure<_Up>&); // not defined template concept __is_range_adaptor_closure = requires (_Tp __t) { __adaptor::__is_range_adaptor_closure_fn(__t, __t); }; The standard requires range adapter closure object type T to model derived_from>. However, the above definition does not consider whether the template parameter of range_adaptor_closure is T, which makes libstdc++ accept the following #include struct _; struct closure : std::ranges::range_adaptor_closure<_> { int operator()(auto&&); }; int main() { auto r = std::views::iota(0) | closure{}; }
[Bug libstdc++/111535] New: _RangeAdaptorClosure's (range | adaptor) operator is underconstrained
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111535 Bug ID: 111535 Summary: _RangeAdaptorClosure's (range | adaptor) operator is underconstrained Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- // range | adaptor is equivalent to adaptor(range). template requires __is_range_adaptor_closure<_Self> && __adaptor_invocable<_Self, _Range> constexpr auto operator|(_Range&& __r, _Self&& __self) { return std::forward<_Self>(__self)(std::forward<_Range>(__r)); } The pipe operator here does not constrain the Range template parameter, but the range adaptor closure object requires arguments to model the range. This makes libstdc++ accept the following #include struct closure : std::ranges::range_adaptor_closure { int operator()(int); }; int main() { auto r = 42 | closure{}; } https://godbolt.org/z/hj9a68ssT
[Bug c++/111410] New: Bogus Wdangling-reference warning with ranges pipe expression in for loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111410 Bug ID: 111410 Summary: Bogus Wdangling-reference warning with ranges pipe expression in for loop Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- #include #include #include int main() { std::vector v{1, 2, 3, 4, 5}; for (auto i : std::span{v} | std::views::take(1)) std::cout << i << '\n'; } GCC-trunk reports the following warning when the -Wall flag is used: :8:51: warning: possibly dangling reference to a temporary [-Wdangling-reference] 8 | for ( auto i : std::span{v} | std::views::take(1)) | ^ https://godbolt.org/z/5jhnTTej9
[Bug libstdc++/111172] New: Dead code in std::get for variant?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72 Bug ID: 72 Summary: Dead code in std::get for variant? Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- In libstdc++'s implementation of variant's std::get, there are static_asserts that require T not to be void, for example: template constexpr _Tp& get(variant<_Types...>& __v) { static_assert(__detail::__variant::__exactly_once<_Tp, _Types...>, "T must occur exactly once in alternatives"); static_assert(!is_void_v<_Tp>, "_Tp must not be void"); constexpr size_t __n = std::__find_uniq_type_in_pack<_Tp, _Types...>(); return std::get<__n>(__v); } But it looks like such static_asserts are *never* fired because the return type already causes a compile error of forming reference to void when T is void.
[Bug c++/111164] New: The error message for a literal operator accepting an argument of the wrong type is confusing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64 Bug ID: 64 Summary: The error message for a literal operator accepting an argument of the wrong type is confusing Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- template int operator ""_x (); int x = "abc"_x; https://godbolt.org/z/aWjM3bx1j The error message given by GCC includes: :4:9: note: expected a constant of type 'char', got 'char' This is paradoxical.
[Bug libstdc++/111138] New: views::zip_transform is underconstrained for empty range pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38 Bug ID: 38 Summary: views::zip_transform is underconstrained for empty range pack Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- #include int main() { std::views::zip_transform(0); // hard error in libstdc++ } https://godbolt.org/z/PYWovhdT4
[Bug c++/111031] New: ICE: internal compiler error: in iterative_hash_template_arg, at cp/pt.cc:1747
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111031 Bug ID: 111031 Summary: ICE: internal compiler error: in iterative_hash_template_arg, at cp/pt.cc:1747 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- I will reduce it if I have the bandwidth. #include namespace std::ranges { template using concat_reference_t = common_reference_t...>; template concept concatable = (requires(const iterator_t in) { { *in } -> convertible_to>; } && ...); template requires concatable class concat_view { }; template concat_view(Rs&&...) -> concat_view...>; } // namespace std::ranges int main() { int x[] = {0, 1, 2}; std::ranges::concat_view r(x); } https://godbolt.org/z/jEh9YzafT
[Bug libstdc++/110862] format out of bands read on format string "{0:{0}"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110862 康桓瑋 changed: What|Removed |Added CC||hewillk at gmail dot com --- Comment #1 from 康桓瑋 --- It does throw: https://godbolt.org/z/5q3bb51YE
[Bug c++/110856] New: GCC rejects template alias of function type as invalid template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110856 Bug ID: 110856 Summary: GCC rejects template alias of function type as invalid template parameter Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- GCC rejects the following valid case: #include #include #include template using identity = T; template using MakeFunType = decltype( [](std::index_sequence) { return std::type_identity...)>{}; }(std::make_index_sequence{}) )::type; template class S { using F1 = std::function>; // ok using F2 = std::function>; // syntax error }; https://godbolt.org/z/fc638b4Y1
[Bug c++/110855] New: std::source_location doesn't work with C++20 coroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110855 Bug ID: 110855 Summary: std::source_location doesn't work with C++20 coroutine Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- When I try to use source_location to debug C++ coroutine: auto initial_suspend(const std::source_location location = std::source_location::current()) { return std::suspend_never{}; } I found that gcc does not allow this with: cc1plus: error: taking address of an immediate function 'static consteval std::source_location std::source_location::current(__builtin_ret_type)' In function 'void bar(bar()::_Z3barv.Frame*)': Not too sure if this is a valid code, although other compilers compile fine. https://godbolt.org/z/qddrsvsT9
[Bug c++/110797] New: GCC rejects std::template same_as form
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110797 Bug ID: 110797 Summary: GCC rejects std::template same_as form Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- #include [[maybe_unused]] std::template same_as auto i = 0; I accidentally found that GCC rejected the above code, not sure if this is valid code. https://godbolt.org/z/edd6zx5df
[Bug c++/110747] New: GCC rejects the syntax for an immediately invoked lambda as a template argument in a requires-clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110747 Bug ID: 110747 Summary: GCC rejects the syntax for an immediately invoked lambda as a template argument in a requires-clause Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- Maybe dup of Bug 91309: template struct S; int main() { return requires { typename S<[]{ return 0; }()>;}; } https://godbolt.org/z/Mha4Waceo
[Bug libstdc++/110593] New: The std::ratio meta arithmetic can accept non-std::ratio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110593 Bug ID: 110593 Summary: The std::ratio meta arithmetic can accept non-std::ratio Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- [ratio.general]: "If a template parameter is named R1 or R2, and the template argument is not a specialization of the ratio template, the program is ill-formed." So for the following libstdc++ needs to be diagnosed, right? #include struct Ratio { constexpr static double num = 0, den = 1; }; static_assert(std::ratio_equal>()); https://godbolt.org/z/MhazY5ecn Only MSVC-STL triggers the static assertion.
[Bug c++/110562] New: GCC does not report the error about lambda contains unexpanded parameter pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110562 Bug ID: 110562 Summary: GCC does not report the error about lambda contains unexpanded parameter pack Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- GCC accepts the following invalid code, which is rejected by Clang and MSVC: template void f() { [](){ T x; }; }; int main() { f(); } https://godbolt.org/z/nreTzPnsK And if we call this lambda immediately like [](){ T x; }(), gcc's error message is quite confusing: :3:14: error: 'T x' has incomplete type 3 | [](){ T x; }(); | ^ https://godbolt.org/z/vfrKGTsjq
[Bug c++/110555] New: internal compiler error: Segmentation fault when using std::ranges::range auto as a template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110555 Bug ID: 110555 Summary: internal compiler error: Segmentation fault when using std::ranges::range auto as a template parameter Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- Original from https://stackoverflow.com/questions/76617167/check-if-a-type-is-convertible-to-a-range-in-c20 #include template void print(R&& range) { if (std::is_same_v) { // ... } } int main() { int arr[] = {0, 1, 2}; print(arr); } https://godbolt.org/z/4Wq5d6z3c
[Bug c++/110486] New: gcc rejects constant expression with consteval lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110486 Bug ID: 110486 Summary: gcc rejects constant expression with consteval lambda Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- GCC rejects the following, while MSVC and Clang compile fine. Not sure if the code is well-formed. #include constexpr auto g = []() consteval { std::vector v; v.push_back(0); return v; }; constexpr auto l = [] { constexpr auto sz = g().size(); return 0; }(); https://godbolt.org/z/WrTx3bn3r
[Bug c++/109859] ICE on concept mis-typed as template type parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109859 康桓瑋 changed: What|Removed |Added CC||hewillk at gmail dot com --- Comment #1 from 康桓瑋 --- Reduced: template concept C = true; template int f(); https://godbolt.org/z/59739vMbj
[Bug c++/109860] New: ICE: in make_typename_type, at cp/decl.cc:4268
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109860 Bug ID: 109860 Summary: ICE: in make_typename_type, at cp/decl.cc:4268 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- #include template concept C = requires { typename std::template tuple; }; https://godbolt.org/z/MrrMvrbhT
[Bug c++/109648] New: ICE: tree check: expected type_pack_expansion or expr_pack_expansion, have error_mark in tsubst_pack_expansion, at cp/pt.cc:13551
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109648 Bug ID: 109648 Summary: ICE: tree check: expected type_pack_expansion or expr_pack_expansion, have error_mark in tsubst_pack_expansion, at cp/pt.cc:13551 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- struct S { int operator[](int); }; auto foo(auto v) { return [&] { return (v()[Is] + ...); }.template operator()<>(); } auto test() { auto v = [] { return S{}; }; return [&] { return (foo(v()[Is]) + ...); }.template operator()<>(); } int main() { test(); } https://godbolt.org/z/Ye89xfKdY
[Bug libstdc++/109525] typo in views::as_const::operator()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109525 --- Comment #1 from 康桓瑋 --- testcase: #include #include std::vector v; std::same_as>> auto r = std::views::as_const(v);
[Bug libstdc++/109525] New: typo in views::as_const::operator()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109525 Bug ID: 109525 Summary: typo in views::as_const::operator() Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- ranges#L9027: else if constexpr (is_lvalue_reference_v<_Range> && constant_range<_Tp> && !view<_Tp>) return ref_view(static_cast(__r)); According to [range.as.const.overview-2.5], the second condition should be constant_range, I think?
[Bug libstdc++/109182] New: unused parameter pack is in expected(in_place_t)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109182 Bug ID: 109182 Summary: unused parameter pack is in expected(in_place_t) Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- include/std/expected#L1305: template constexpr explicit expected(in_place_t) noexcept : expected() { } Although this seems to be unobservable, it doesn't seem to make much sense to introduce an unused parameter pack here. I suspect that this may be a typo. Please correct me if this is intentional.
[Bug libstdc++/108760] New: ranges::iota is not included in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108760 Bug ID: 108760 Summary: ranges::iota is not included in Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- It seems wrong that libstdc++ needs to include for ranges::iota. #include int main() { int x[] = {0, 0, 0, 0, 0}; std::ranges::iota(x, 0); } https://godbolt.org/z/33EPeqd1b
[Bug libstdc++/108362] New: views::istream is SFINAE-unfriendly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108362 Bug ID: 108362 Summary: views::istream is SFINAE-unfriendly Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- Similar issue with https://github.com/microsoft/STL/pull/3335. #include #include template concept can_istream_view = requires { std::views::istream(std::cin); }; struct S { }; static_assert(!can_istream_view); https://godbolt.org/z/b3W1KsPWd
[Bug libstdc++/108291] New: chunk_by_view::find-next/find-prev uses wrong lambda helper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108291 Bug ID: 108291 Summary: chunk_by_view::find-next/find-prev uses wrong lambda helper Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- constexpr iterator_t<_Vp> _M_find_next(iterator_t<_Vp> __current) { __glibcxx_assert(_M_pred.has_value()); auto __pred = [this](_Tp&& __x, _Tp&& __y) { return !bool((*_M_pred)(std::forward<_Tp>(__x), std::forward<_Tp>(__y))); }; auto __it = ranges::adjacent_find(__current, ranges::end(_M_base), __pred); return ranges::next(__it, 1, ranges::end(_M_base)); } This template lambda assumes that both parameters should have the same type, which will affect the constraint check, it should be auto __pred = [this](_Tp&& __x, _Up&& __y) { return !bool((*_M_pred)(std::forward<_Tp>(__x), std::forward<_Up>(__y))); }; testcase: #include int main() { std::string_view s = "hello"; auto r = s | std::views::chunk_by(std::less{}); ++r.begin(); } https://godbolt.org/z/rcfqqcG66
[Bug libstdc++/108046] New: The dot in the floating-point alternative form has wrong position
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108046 Bug ID: 108046 Summary: The dot in the floating-point alternative form has wrong position Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- #include #include int main() { std::cout << std::format("{:#.0}\n", 10.); std::cout << std::format("{:#.1}\n", 10.); std::cout << std::format("{:#.0g}\n", 10.); } libstdc++ gives: 1e+01. 1e+01. 1e+01 But they should all be "1.e+01" https://godbolt.org/z/Y41ve6E7W
[Bug libstdc++/108024] New: std::format_string's constructor has the wrong constraint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108024 Bug ID: 108024 Summary: std::format_string's constructor has the wrong constraint Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- format#L3628: template template> _Tp> consteval basic_format_string<_CharT, _Args...>:: basic_format_string(const _Tp& __s) : _M_str(__s) >From [format.fmt.string]: "Constraints: const T& models convertible_to>." We should use the requires-clause to constrain const _Tp instead of _Tp. Testcase: #include struct Str { consteval operator std::string_view() const { return ""; } operator std::string_view() = delete; }; int main() { return std::format(Str{}).size(); } https://godbolt.org/z/xjq5K9YGo