-
Notifications
You must be signed in to change notification settings - Fork 10.5k
IRGen: Outlining thunks don't need to receive fixed-size metadata #15972
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 |
Build failed |
ce3df8e
to
a2c6f37
Compare
@swift-ci Please test |
@swift-ci Please test source compatibility |
Build failed |
Build failed |
@DougGregor I'm not going to bother adding the test case unless the source compat suite passes, but it fixes that MyPrivate/OtherPrivate example you showed me. |
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 works on my example and appears to work in the larger project I reduced it from (see rdar://problem/39470607), and it looks safe...
a2c6f37
to
9fb0248
Compare
They're not used inside the thunk so it's a waste passing them in, and if they involve private types from a different translation unit we will get a linking error from referencing the metadata accessor function. Fixes the test case in <rdar://problem/39470607>, but the more general problem remains.
9fb0248
to
39a65ab
Compare
@swift-ci Please smoke test |
There is a general problem where if a public fixed-layout type contains internal or private fields, we have trouble manipulating values of the type from outside the module. This patch doesn't address the issue, but fixes one specific case where we don't need the metadata anyway.