]> git.ipfire.org Git - thirdparty/gcc.git/commit
c++, coroutines: Revise promise construction/destruction.
authorIain Sandoe <iain@sandoe.co.uk>
Sat, 31 Aug 2024 12:08:42 +0000 (13:08 +0100)
committerIain Sandoe <iain@sandoe.co.uk>
Thu, 5 Sep 2024 19:19:42 +0000 (20:19 +0100)
commit7d1483921941d21d91f929ef0d59a9794b1946b4
treea4f06925dd5bfa421d663ca5f8ab3901d2a7679b
parent37977343ff4f9dcb047d966d8cbaa222964763f9
c++, coroutines: Revise promise construction/destruction.

In examining the coroutine testcases for unexpected diagnostic output
for 'Wall', I found a 'statement has no effect' warning for the promise
construction in one case.  In particular, the case is where the users
promise type has an implicit CTOR but a user-provided DTOR. Further, the
type does not actually need constructing.

In very early versions of the coroutines code we used to check
TYPE_NEEDS_CONSTRUCTING() to determine whether to attempt to build
a constructor call for the promise.  During review, it was suggested
to use type_build_ctor_call () instead.

This latter call checks the constructors in the type (both user-defined
and implicit) and returns true, amongst other cases if any of the found
CTORs are marked as deprecated.

In a number of places (for example [class.copy.ctor] / 6) the standard
says that some version of an implicit CTOR is deprecated when the user
provides a DTOR.

Thus, for this specific arrangement of promise type, type_build_ctor_call
returns true, because of (for example) a deprecated implicit copy CTOR.

We are not going to use any of the deprecated CTORs and thus will not
see warnings from this - however, since the call returned true, we have
now determined that we should attempt to build a constructor call.

Note as above, the type does not actually require construction and thus
one might expect either a NULL_TREE or error_mark_node in response to
the build_special_member_call ().  However, in practice the function
returns the original instance object instead of a call or some error.

When we add that as a statement it triggers the 'statement has no effect'
warning.

The patch here rearranges the promise construction/destruction code to
allow for the case that a DTOR is required independently of a CTOR. In
addition, we check that the return from build_special_member_call ()
has side effects before we add it as a statement.

gcc/cp/ChangeLog:

* coroutines.cc
(cp_coroutine_transform::build_ramp_function): Separate the
build of promise constructor and destructor.  When evaluating
the constructor, check that build_special_member_call returns
an expression with side effects before adding it.

Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
gcc/cp/coroutines.cc