diff options
author | Jason Merrill <jason@redhat.com> | 2021-05-04 21:33:36 -0400 |
---|---|---|
committer | Jason Merrill <jason@redhat.com> | 2021-05-07 12:07:04 -0400 |
commit | 14ed21f8749ae359690d9c4a69ca38cc45d0d1b0 (patch) | |
tree | e2f4bfe98c12d38717b5d1a4a9e500695f425e64 /gcc/builtins.c | |
parent | 601191b2a48cb8f4657bb2fa2270a7fde9d52e9c (diff) | |
download | gcc-14ed21f8749ae359690d9c4a69ca38cc45d0d1b0.zip gcc-14ed21f8749ae359690d9c4a69ca38cc45d0d1b0.tar.gz gcc-14ed21f8749ae359690d9c4a69ca38cc45d0d1b0.tar.bz2 |
c++: don't call 'rvalue' in coroutines code
A change to check glvalue_p rather than specifically for TARGET_EXPR
revealed issues with the coroutines code's use of the 'rvalue' function,
which shouldn't be used on class glvalues, so I've removed those calls.
In build_co_await I just dropped them, because I don't see anything in the
co_await specification that indicates that we would want to move from an
lvalue result of operator co_await. And simplified that code while I was
touching it; cp_build_modify_expr (...INIT_EXPR...) will call the
constructor.
In morph_fn_to_coro I changed the handling of the rvalue reference coroutine
frame field to use move, to treat the rval ref as an xvalue. I used
forward_parm to pass the function parms to the constructor for the field.
And I simplified the return handling so we get the desired rvalue semantics
from the normal implicit move on return.
I question default-initializing the non-void return value of the function if
get_return_object returns void; I'm not messing with it here, but I've filed
PR100476 about it.
gcc/cp/ChangeLog:
* coroutines.cc (build_co_await): Don't call 'rvalue'.
(flatten_await_stmt): Simplify initialization.
(morph_fn_to_coro): Change 'rvalue' to 'move'. Simplify.
gcc/testsuite/ChangeLog:
* g++.dg/coroutines/coro-bad-gro-00-class-gro-scalar-return.C:
Adjust diagnostic.
Diffstat (limited to 'gcc/builtins.c')
0 files changed, 0 insertions, 0 deletions