libstdc++: Give ranges::empty() a concrete return type (PR 93978)
authorPatrick Palka <ppalka@redhat.com>
Thu, 5 Mar 2020 15:04:06 +0000 (10:04 -0500)
committerPatrick Palka <ppalka@redhat.com>
Fri, 6 Mar 2020 14:22:54 +0000 (09:22 -0500)
commit6d082cd90131a9c0ce3142217e84194a5bf0de27
tree412df4c8feba360c4670204a334a4eb31bde7dc8
parent4cdcb2c92a128d2a30a6110084b7ab2f9995c683
libstdc++: Give ranges::empty() a concrete return type (PR 93978)

This works around PR 93978 by avoiding having to instantiate the body of
ranges::empty() when checking the constraints of view_interface::operator
bool().  When ranges::empty() has an auto return type, then we must instantiate
its body in order to determine whether the requires expression {
ranges::empty(_M_derived()); } is well-formed.  But this means instantiating
view_interface::empty() and hence view_interface::_M_derived(), all before we've
yet deduced the return type of join_view::end().  (The reason
view_interface::operator bool() is needed in join_view::end() in the first place
is because in this function we perform direct initialization of
join_view::_Sentinel from a join_view, and so we try to find a conversion
sequence from the latter to the former that goes through this conversion
operator.)

Giving ranges::empty() a concrete return type of bool should be safe according
to [range.prim.empty]/4 which says "whenever ranges::empty(E) is a valid
expression, it has type bool."

This fixes the test case in PR 93978 when compiling without -Wall, but with -Wall
the test case still fails due to the issue described in PR c++/94038, I think.
I still don't quite understand why the test case doesn't fail without -O.

libstdc++-v3/ChangeLog:

PR libstdc++/93978
* include/bits/range_access.h (__cust_access::_Empty::operator()):
Declare return type to be bool instead of auto.
* testsuite/std/ranges/adaptors/93978.cc: New test.
libstdc++-v3/ChangeLog
libstdc++-v3/include/bits/range_access.h
libstdc++-v3/testsuite/std/ranges/adaptors/93978.cc [new file with mode: 0644]