-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[SILGen] Don't SILGen an @objc entry point for a deinit with no body #19472
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 |
Build failed |
…*sigh* right. |
d6ae891
to
9f6a777
Compare
@swift-ci Please test |
Build failed |
Build failed |
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.
Why is this specific to destructors? Does constructor and method emission need similar checks?
Hm. We have been testing those with non- (Right now we're mostly trying to get the stdlib and overlays all building successfully, and this one came up in Foundation while the others didn't. But that doesn't mean we shouldn't have tests.) |
9f6a777
to
dfdf01c
Compare
@swift-ci Please smoke test |
Uh, hm, that's fun. I guess we're emitting unnecessary thunks for constructors too, but it's only a problem on Linux! |
In general we'll want to investigate what we are and aren't SILGen-ing for textual interfaces of resilient modules, but for fragile modules we may as well generate everything we can for potential optimization purposes.
dfdf01c
to
6d4a1f7
Compare
@swift-ci Please smoke test |
Ugh, right, that kills the previous job for normal tests. Oh well. |
In general we'll want to investigate what we are and aren't SILGen-ing for textual interfaces of resilient modules, but for fragile modules we may as well generate everything we can for potential optimization purposes.