-
Notifications
You must be signed in to change notification settings - Fork 10.5k
Proper fix for ObjC async jump to null #58515
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
@swift-ci please test |
8a59d48
to
bd6b3e9
Compare
@swift-ci please test |
I tried to generalize this late ArgumentScope pop using
|
macOS failures from this batch:
Seems to indicate that the error value for calling async ObjC methods that return a YES/NO based on whether the handler was invoked are returning the wrong value on the error path:
|
8476f88
to
31a0fc9
Compare
@swift-ci please test |
when two objc async functions are composed with each other, i.e., f(g()), then the clean-ups for g() would get emitted at an unexpected time, namely, during the suspension for the call to f(). This means that using a clean-up to emit the executor-hop breadcrumb was incorrect. The hop could appear between a get_async continuation and its matching await_continuation, which is an unsupported nested suspension. This commit fixes that by removing the use of the breadcrumb clean-up in favor of providing that breadcrumb directly to the result plan, so that it may be emitted later on when the result plan sees fit. Fixes rdar://91502776
31a0fc9
to
814fb42
Compare
@swift-ci please test |
@swift-ci please smoke test and merge |
1 similar comment
@swift-ci please smoke test and merge |
@swift-ci please smoke test and merge |
What makes this PR "proper" is that it is not just a revert of the code that caused the regression, but a fix made on top of that.
when two objc async functions are composed with each other,
i.e., f(g()), then the clean-ups for g() would get emitted
at an unexpected time, namely, during the suspension for
the call to f(). This means that using a clean-up to emit
the executor-hop breadcrumb was incorrect. The hop could
appear between a get_async continuation and its matching
await_continuation, which is an unsupported nested suspension.
This commit fixes that by removing the use of the breadcrumb
clean-up in favor of providing that breadcrumb directly to
the result plan, so that it may be emitted later on when the
result plan sees fit.
One nice benefit of this change is that the hops are now
consistently the first instruction in the successor blocks.
Fixes rdar://91502776