[PATCH] D115219: [C++20] [Coroutines] Mark coroutine done if unhandled_exception throws

John McCall via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Tue Dec 7 11:20:23 PST 2021


rjmccall added a comment.

In D115219#3175660 <https://reviews.llvm.org/D115219#3175660>, @ChuanqiXu wrote:

> In D115219#3175582 <https://reviews.llvm.org/D115219#3175582>, @rjmccall wrote:
>
>> I agree that you shouldn't call `suspend`, but doesn't `coro.end` have the behavior of marking the coroutine done?  Should we just be calling `coro.end` on this path?
>
> @rjmccall great insight! `coro.end` wouldn't marking the coroutine done previously. But its place is perfect to do so. I have added the codes to mark the coroutine as done for `coro.end` in the unwind path. And I have checked the behavior. The exception happened earlier wouldn't run into the path of coro.end exists. So the behavior is satisfying. The only defect might be that the behavior is C++'s semantic. Although, there might be a problem if there is another language also uses switch-resumed ABI one day. I think the current approach is much better at least it has and would generate less code.

Okay.  Well, I'm glad it works.  I guess I find it a little strange that `coro.end` doesn't already mark the coroutine done.  I guess the normal C++ lowering always generates a final suspension before reaching a non-unwind `coro.end`?  There are a lot of semantic differences between throwing out of a C++ coroutine and returning out of it that I always find surprising.

Something ultimately invalidates the coroutine handle by deallocating the frame, right?  When does that happen when throwing out of a coroutine?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D115219/new/

https://reviews.llvm.org/D115219



More information about the cfe-commits mailing list