On 5/14/20 9:04 AM, Iain Sandoe wrote:
Hi
thanks for the review and pointers ...
Nathan Sidwell <nat...@acm.org> wrote:
On 5/13/20 9:26 AM, Iain Sandoe wrote:
Nathan Sidwell <nat...@acm.org> wrote:
On 5/13/20 6:59 AM, Iain Sandoe wrote:
This is the equivalent of finish_return_stmt () in the parser, it knows nothing
of the eventual morphing of local vars (or parms) into frame references.
So I only need to handle what can be returned by "expr = cp_parser_expression
(parser);”
dependent expressions are dealt with above, with an early return with
“type_unknown_node”.
Unfortunately, the code in finish_return_stmt / and check_return_expr is too
retval-centric to be
re-used in this context. However, I have taken from it in determining a
sequence of operations,
and in the use of treat_lvalue_as_rvalue_p() - with the additional criterion
that the object must
not be volatile (check_return_expr checks that in a different predicate, that’s
not usable here).
tested on x86_64-darwin so far,
does this now look OK for master (after checking on Linux too)?
and for 10.2 after some bake time on master?
thanks
Iain
=====
This is a case where the standard contains conflicting information.
after discussion between implementators, the accepted intent is of
[class.copy.elision]. This amends the handling of co_return statements
to follow that.
gcc/cp/ChangeLog:
2020-05-14 Iain Sandoe <i...@sandoe.co.uk>
* coroutines.cc (finish_co_return_stmt): Implement rules
from [class.copy.elision] /3.
Yeah, this is better, ok for master and 10.2 (when you're ready)
nathan
--
Nathan Sidwell
