aboutsummaryrefslogtreecommitdiff
path: root/gcc/cp/parser.cc
diff options
context:
space:
mode:
authorIain Sandoe <iain@sandoe.co.uk>2024-08-31 13:08:42 +0100
committerIain Sandoe <iain@sandoe.co.uk>2024-09-05 20:19:42 +0100
commit7d1483921941d21d91f929ef0d59a9794b1946b4 (patch)
treea4f06925dd5bfa421d663ca5f8ab3901d2a7679b /gcc/cp/parser.cc
parent37977343ff4f9dcb047d966d8cbaa222964763f9 (diff)
downloadgcc-7d1483921941d21d91f929ef0d59a9794b1946b4.zip
gcc-7d1483921941d21d91f929ef0d59a9794b1946b4.tar.gz
gcc-7d1483921941d21d91f929ef0d59a9794b1946b4.tar.bz2
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>
Diffstat (limited to 'gcc/cp/parser.cc')
0 files changed, 0 insertions, 0 deletions