-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[SILGen] Use opaque AP for ObjC-async returns. #42485
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
Previously, the AbstractionPattern that was used for the value "returned" (i.e. via a completion handler) from ObjC mostly (but not quite always) was "type". The generated completion handler correctly (because this is required in order to call _resumeUnsafeContinuation) reabstracted the block (e.g. from @convention(block) to @Substituted <T> () -> @out T for <()>). The callee of the ObjC function, however, loaded the function from the block as if it were not reabstracted (e.g. () -> ()). On most platforms, that happened to work. On arm64e, that difference in types caused in a difference in pointer signing, resulting in a failure at runtime. rdar://85526879 rdar://85526916
@swift-ci please test |
@swift-ci Please test Apple Silicon macOS Platform |
@swift-ci please test macOS platform |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems reasonable to me but I would defer to @jckarter
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks right. Maybe we could add an execution test that tries to call through the function value too—if it's not correctly abstracted, then we're likely to crash on any platform, not just arm64e.
Definitely! Actually the execution tests do call through the function value that's returned. That's what was failing on arm64e. For example,
|
Interesting that that wouldn't crash on other platforms already too. Maybe an execution test that passes through a function with nontrivial arguments and returns would be more likely to expose the mismatch. |
Verify the recent fix at swiftlang#42485.
Added more execution tests which return differently shaped function pointers in #42508 . |
Verify the recent fix at swiftlang#42485.
Previously, the AbstractionPattern that was used for the value "returned" (i.e. via a completion handler) from ObjC mostly (but not quite always) was "type".
The generated completion handler correctly (because this is required in order to call
_resumeUnsafeContinuation)
reabstracted the block (e.g. from@convention(block) () -> ())
to@substituted <T> () -> @out T for <()>
). The callee of the ObjC function, however, loaded the function from the block as if it were not reabstracted (e.g.() -> ()
).On arm64e, that difference in types caused in a difference in pointer signing, resulting in a failure at runtime.
rdar://85526879
rdar://85526916