[Bug c++/98704] coroutine_handle::done() == false after promise's unhandled_exception() has thrown

["iains at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98704

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
     Ever confirmed|0                           |1
           Assignee|unassigned at gcc dot gnu.org      |iains at gcc dot gnu.org
   Last reconfirmed|                            |2021-03-12

--- Comment #2 from Iain Sandoe <iains at gcc dot gnu.org> ---
Created attachment 50376
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50376&action=edit
Patch under test

Thanks for the report, and suggested fix.

This is the subject of CWG 2541 (about the wording, which is potentially
misleading).

Your possible fix doesn't do quite the right thing (because of said misleading
wording, I suspect) - it's necessary to ensure that the destroy() entry does
the correct thing when called.

=======

When promise.unhandled_exception () is entered, the coroutine is
considered to be still running - returning from the method will
cause the final await expression to be evaluated.

If the method throws, that action is considered to make the
coroutine suspend (since, otherwise, it would be impossible to
reclaim its resources, since one cannot destroy a running coro).

The wording issue is to do with how to represent the place at
which the coroutine should be considered suspended.

For the implementation here, that place is immediately before the
promise life-time ends. A handler for the rethrown exception, can
thus call xxxx.destroy() which will run DTORs for the promise and
any parameter copies [as needed] then the coroutine frame will be
deallocated.

At present, we also set "done=true" in this case (for compatibility
with other current implementations). One might consider 'done()'
to be misleading in the case of an abnormal termination - that is
also part of the CGW 2451 discussion.

I modified the reproducer into a test case that also checks that
the resources are properly cleaned up on an exceptional termination.