[5.5] [SILGen] Handle foreign funcs with error and async conventions. #38861
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Previously, SILGen assumed that a foreign function could either have a
foreign async convention or a foreign error convention, but if it had
both, the error would be subsumed into the completion. That resulted in
failures to emit code for async calls of functions like
```
- (BOOL)minimalWithError:(NSError* _Nullable*)error
completionHandler:(void (^ _Nonnull)(void))completionHandler;
```
Here, SILGen gains the ability to emit such functions. To enable that,
a few changes were required when both conventions are present:
- a separate argument for each convention is used
- the ResultPlan is a ForeignErrorResultPlan nesting a
ForeignAsyncResultPlan
- the continuation is always of the form UnsafeContinuation<_, Error>
regardless of whether the completion handler takes an error
- the foreign error block fills the continuation with the error that was
passed by reference out of the ObjC method call
- the foreign error block branches to the block containing the await
instruction
rdar://80704984
|
@swift-ci please test |
|
@swift-ci please nominate |
tbkka
approved these changes
Aug 17, 2021
AnthonyLatsis
added
🍒 release cherry pick
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
5.5 Summary: Fix compiler crashes during emission of calls-as-async to ObjC functions that take error out parameters.
Explanation: When an ObjC method is called-as-async from Swift, SILGen generates code to handle ObjC's conventions around error handling. For example, ObjC often communicates errors via an NSError or flag argument passed to the completion handler. ObjC may, however, also communicate an error via a NSError out parameter at the top level such as
Previously, SILGen assumed that a foreign function could either have a foreign async convention or a foreign error convention, but not both. Consequently, SILGen failed when attempting to call-as-async that method.
Here, SILGen gains the ability to emit calls-as-async to such functions. To enable that, the ResultPlan for such calls is now a ForeignErrorResultPlan nesting a ForeignAsyncResultPlan. The ForeignAsyncResultPlan-created continuation used for the call is now always of the form
UnsafeContinuation<_, Error>regardless of whether the ObjC method's completion has an error or flag argument. That in turn enables the foreign error block--which is branched to if the error out parameter/return value indicates an error--to fill that continuation with the error and then to branch to the block which awaits the fulfillment of the continuation.Issue: rdar://80704984
Original PR: #38740
Testing: New regression tests, Swift CI
Reviewed by: Joe Groff
Risk: Low.
Scope: Limited to Swift import of ObjC methods as async functions.