-
Notifications
You must be signed in to change notification settings - Fork 10.5k
Thunk linkage and fragility cleanup #8422
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
Thunk linkage and fragility cleanup #8422
Conversation
This generalizes a hack where re-abstraction thunks become fragile on contact with fragile functions. The old policy was: - [fragile] functions always serialized - [reabstraction_thunk] transitively referenced from fragile always serialized The new policy is: - [serialized] functions always serialized - [serializable] functions transitively referenced from serialized functions are always serialized - Most kinds of thunks can now be [serializable], allowing them to be shared between serialized and non-serialized code without any issues, as long as the body of the thunk is sufficiently "simple" (doesn't reference private symbols or performs direct access to resilient types)
This code has been commented out for years, doesn't compile, and when I changed it to compile it blew up building overlays. I don't feel it adds any value to have it around so I'm removing it.
@swift-ci Please test |
Build failed |
Build failed |
This fixes a crash when referencing partially-applied methods from @_inlineable functions. Also, curry thunks for private methods do not need shared linkage; private is sufficient.
8f40288
to
91b980b
Compare
@swift-ci Please test |
1 similar comment
@swift-ci Please test |
@swift-ci Please smoke test |
1 similar comment
@swift-ci Please smoke test |
Build failed |
Pop a yak off the stack:
I just merged the past part (#8407). This is the second-to-last bit.