public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libstdc++/109474] New: chunk_by doesn't work for ranges of proxy references
@ 2023-04-11 17:57 barry.revzin at gmail dot com
2023-04-11 18:09 ` [Bug libstdc++/109474] " ppalka at gcc dot gnu.org
2023-04-12 2:45 ` barry.revzin at gmail dot com
0 siblings, 2 replies; 3+ messages in thread
From: barry.revzin at gmail dot com @ 2023-04-11 17:57 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109474
Bug ID: 109474
Summary: chunk_by doesn't work for ranges of proxy references
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: barry.revzin at gmail dot com
Target Milestone: ---
Reduced example from Conor's tweet
(https://twitter.com/code_report/status/1645831980473282560):
#include <vector>
#include <ranges>
void f(std::vector<bool> v) {
auto z = std::views::chunk_by(
v,
[](auto&& lhs, auto&& rhs){
return true;
});
auto i = z.begin();
}
This fails because the find_next implementation right now
(https://github.com/gcc-mirror/gcc/blob/0c5e64c4249322a178e1a0e843874e4d6b43b992/libstdc%2B%2B-v3/include/std/ranges#L6741-L6750)
passes a predicate into adjacent_find that requires both parameters be the same
type, but in this case indirect_binary_predicate is checking that it's
invocable with both value_type& (bool&) and reference
(vector<bool>::reference), which in this case are different types.
The original example was a zip_view of two ranges - which likewise would have
value_type& and reference be different.
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug libstdc++/109474] chunk_by doesn't work for ranges of proxy references
2023-04-11 17:57 [Bug libstdc++/109474] New: chunk_by doesn't work for ranges of proxy references barry.revzin at gmail dot com
@ 2023-04-11 18:09 ` ppalka at gcc dot gnu.org
2023-04-12 2:45 ` barry.revzin at gmail dot com
1 sibling, 0 replies; 3+ messages in thread
From: ppalka at gcc dot gnu.org @ 2023-04-11 18:09 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109474
Patrick Palka <ppalka at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |DUPLICATE
--- Comment #1 from Patrick Palka <ppalka at gcc dot gnu.org> ---
D'oh, thanks for the bug report. Looks like a dup of PR108291, which
unfortunately slipped through the cracks..
*** This bug has been marked as a duplicate of bug 108291 ***
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug libstdc++/109474] chunk_by doesn't work for ranges of proxy references
2023-04-11 17:57 [Bug libstdc++/109474] New: chunk_by doesn't work for ranges of proxy references barry.revzin at gmail dot com
2023-04-11 18:09 ` [Bug libstdc++/109474] " ppalka at gcc dot gnu.org
@ 2023-04-12 2:45 ` barry.revzin at gmail dot com
1 sibling, 0 replies; 3+ messages in thread
From: barry.revzin at gmail dot com @ 2023-04-12 2:45 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109474
--- Comment #2 from Barry Revzin <barry.revzin at gmail dot com> ---
Serves me right for only checking vector<int> (which worked) and vector<bool>
(which didn't) and not bothering to check vector<int> const (which also doesn't
work) and thus overly complicating the bug report.
I got too excited that vector<bool> played an important role I guess.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2023-04-12 2:45 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-04-11 17:57 [Bug libstdc++/109474] New: chunk_by doesn't work for ranges of proxy references barry.revzin at gmail dot com
2023-04-11 18:09 ` [Bug libstdc++/109474] " ppalka at gcc dot gnu.org
2023-04-12 2:45 ` barry.revzin at gmail dot com
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).