Re: [PATCH v2] coroutines: Implicitly movable objects should use move CTORs for co_return.

[Nathan Sidwell <nathan@acm.org>]

On 5/14/20 9:04 AM, Iain Sandoe wrote:
> Hi
> 
> thanks for the review and pointers ...
> 
> Nathan Sidwell <nathan@acm.org> wrote:
> 
>> On 5/13/20 9:26 AM, Iain Sandoe wrote:
>>> Nathan Sidwell <nathan@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  <iain@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