[PATCH] D115219: [C++20] [Coroutines] Mark coroutine done if unhandled_exception throws
John McCall via Phabricator via llvm-commits
llvm-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 llvm-commits
mailing list