This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/86588] New: peculiar build issue using range-v3
- From: "h2+bugs at fsfe dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 19 Jul 2018 13:50:26 +0000
- Subject: [Bug c++/86588] New: peculiar build issue using range-v3
- Auto-submitted: auto-generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86588
Bug ID: 86588
Summary: peculiar build issue using range-v3
Product: gcc
Version: 7.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: h2+bugs at fsfe dot org
Target Milestone: ---
I have attached a code sample below and will provide an intermediate file that
shows that various forms of initialisation fail to build, while equivalent (at
least some) pass [all that are commented out fail, the last two are the only
that pass].
Since range-v3 pulls in a large amount of code the intermediate files are quite
large and I have as of yet been unsuccessful in reducing this to something that
still fails, but I hope someone with more expertise can track the compiler
while it tries/fails to deduce the type.
tested versions:
g++7 (FreeBSD Ports Collection) 7.3.1 20180712
g++8 (FreeBSD Ports Collection) 8.1.1 20180713
For reference also the issue at range-v3:
https://github.com/ericniebler/range-v3/issues/860
std::string vec{"foo\nbar"};
seqan3::detail::view_take_line v1(ranges::view::all(vec));
assert("foo" == std::string(v1));
assert(ranges::BidirectionalRange<decltype(v1)>());
assert(ranges::View<decltype(v1)>());
// auto v2 = v1 | ranges::view::reverse; // #1
// auto v2 = ranges::reverse_view<decltype(v1)>{v1}; // #2
using t = ranges::reverse_view<decltype(v1)>;
// auto v2 = t(v1); // #3
// auto v2 = t{v1}; // #3b
// t v2 = t(v1); // #4
// t v2 = t{v1}; // #4b
// t v2 = v1; // #5
t v2(v1); // #6
t v3{v1}; // #6b
assert("oof" == std::string(v2));