[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
[Bug libstdc++/107871] _Iter_sink:: _M_overflow missing some difference type casting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107871
--- Comment #8 from 康桓瑋 ---
(In reply to Jonathan Wakely from comment #4)
> Maybe you could legally do:
>
> using difference_type = iterator_t>;
>
> but maybe just don't do that. If things break when you do dumb things, don't
> do those things.
A more uncontrived example would be:
std::vector v(10);
auto r = std::views::iota((unsigned __int128)0) |
std::views::transform([&](auto i) -> auto& { return v[i]; });
auto s = std::format_to_n(r.begin(), 5, "{}", "");
[Bug libstdc++/107871] _Iter_sink:: _M_overflow missing some difference type casting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107871
--- Comment #5 from 康桓瑋 ---
(In reply to Jonathan Wakely from comment #4)
> Maybe you could legally do:
>
> using difference_type = iterator_t>;
>
> but maybe just don't do that. If things break when you do dumb things, don't
> do those things.
I would never do that.
However, I see that you seem to have considered this issue elsewhere, in
format#L2561:
if constexpr (!is_integral_v
|| sizeof(__n) > sizeof(size_t))
{
// __int128 or __detail::__max_diff_type
auto __m = (decltype(__n))(size_t)-1;
if (__n > __m)
__n = __m;
}
[Bug libstdc++/107871] _Iter_sink:: _M_overflow missing some difference type casting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107871 --- Comment #2 from 康桓瑋 --- This is just an example. So, are users not allowed to define integer-like class types?
[Bug libstdc++/107871] New: _Iter_sink:: _M_overflow missing some difference type casting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107871
Bug ID: 107871
Summary: _Iter_sink:: _M_overflow missing some difference type
casting
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
struct O {
using difference_type = std::ranges::__detail::__max_diff_type;
O& operator=(const char&);
O& operator*();
O& operator++();
O& operator++(int);
};
int main() {
std::format_to_n(O{}, 4, "{}", " ");
}
https://godbolt.org/z/x78qjfse6
[Bug c++/107800] New: confusing message with to_address in C++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107800 Bug ID: 107800 Summary: confusing message with to_address in C++17 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: --- When I try to use C++20 to_address in C++17 code, the compiler error message is confusing: :2:1: note: 'std::to_address' is defined in header ''; did you forget to '#include '? 1 | #include +++ |+#include 2 | This error message should be removed since I did include . https://godbolt.org/z/T1PEnTdGY
[Bug libstdc++/107572] New: cartesian_product_view invokes the begin of input_range twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107572
Bug ID: 107572
Summary: cartesian_product_view invokes the begin of
input_range twice
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#L8069:
auto __it = __detail::__tuple_transform(ranges::begin, _M_bases);
if (!__empty_tail)
std::get<0>(__it) =
__detail::__cartesian_common_arg_end(std::get<0>(_M_bases));
return _Iterator{*this, std::move(__it)};
This *always* invokes begin twice for the first range, which is undefined
behavior when it is an input_range.
testcase (https://godbolt.org/z/7hfP8xM6a):
#include
#include
#include
std::istringstream ints("0 1 2 3 4");
struct istream_range {
auto begin() { return std::istream_iterator{ints}; }
auto end() { return std::istream_iterator{}; }
};
int main() {
istream_range r;
fmt::print("{}\n", std::views::cartesian_product(r)); // prints [(0),
(2), (3), (4)]
}
[Bug libstdc++/107371] New: __adaptor::_RangeAdaptor rejects the explicit move constructor case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107371
Bug ID: 107371
Summary: __adaptor::_RangeAdaptor rejects the explicit move
constructor case
Product: gcc
Version: 12.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:
#include
struct A {
A() = default;
explicit A(A&&) { }
operator int() { return 5; }
};
int main() {
auto r = std::views::iota(0) | std::views::take(A{});
}
https://godbolt.org/z/EEarj7he8
[Bug libstdc++/107313] New: typo in stride_view::_Iterator::operator-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107313
Bug ID: 107313
Summary: typo in stride_view::_Iterator::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: ---
std/ranges#L7877:
friend constexpr difference_type
operator-(default_sentinel_t __y, const _Iterator& __x)
requires sized_sentinel_for, iterator_t<_Base>>
{ return __detail::__div_ceil(__x._M_end, __x._M_current, __x._M_stride); }
The ',' should be '-'.
testcase:
#include
#include
int main() {
auto i = std::views::istream(std::cin);
auto r = std::views::counted(i.begin(), 4)
| std::views::stride(2);
auto d = r.begin() - r.end();
}
[Bug libstdc++/106803] views::adjacent_transform should not return views::empty> when N == 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106803
--- Comment #5 from 康桓瑋 ---
(In reply to Patrick Palka from comment #4)
> Fixed, thanks very much for the bug reports.
Hey Patrick, thanks for the prompt fix.
However, I think there may be some issues with this fix, consider:
struct F {
F() = default;
F(const F&) = delete;
void operator()() = delete;
};
auto r = std::views::zip_transform(F{});
There are two problems here, the first less important one is that F is not
callable, so views::empty<...> in the function body would be a hard error; the
second one is that when empty pack, [range.zip.transform.overview] explicitly
requires that F must be copy_constructible (this should be move_constructible
because of p2494, I have submitted LWG for this), so even if F provides
operator(), we still need to reject the above.
[Bug c++/106810] New: Unexpected constraint recursion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106810
Bug ID: 106810
Summary: Unexpected constraint recursion
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: ---
GCC will produce recursive constraints check for the following code, suggesting
that there may be a language bug (or maybe not a bug).
https://godbolt.org/z/vYd7a5f19
#include
template
struct I {
using value_type = int;
using difference_type = int;
value_type& operator*() const;
I& operator++();
I operator++(int);
template S>
friend bool operator==(I, S);
};
static_assert(std::sentinel_for>);
[Bug libstdc++/106803] views::adjacent_transform should not return views::empty> when N == 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106803 --- Comment #1 from 康桓瑋 --- Another issue is that views::zip_transform returns views::empty>> when N == 0, which is not strictly true, the standard requires that the return is the result of the *lvalue* F being invoked, that is, views::empty&>>>.
[Bug libstdc++/106803] New: views::adjacent_transform should not return views::empty> when N == 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106803 Bug ID: 106803 Summary: views::adjacent_transform should not return views::empty> when N == 0 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: --- views::adjacent_transform seems to incorrectly copy-paste views::adjacent's operator(), which makes it return views::empty> when N == 0, however, according to the standard, it should return views::zip_transform(F) which is views::empty>>.
