Implement Swift support for Objective-C resilient class stubs [5.1] #23746
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
This cleans up some code. I'm keeping the ResilienceStrategy enum around though, in case we want to use it to version the ABI in the future.
…estry() This replaces ClassDecl::hasObjCMembers() and some hand-coded walks.
This adds a new tail-allocated field to class context descriptors storing a pointer to an Objective-C class stub. When the stub is present, we use the new _objc_realizeClassFromSwift() entry point to realize the class instead of calling objc_readClassPair(). This should attach categories to the realized class, if they were emitted to reference the stub.
Non-generic classes with resilient ancestry do not have statically-emitted metadata, so we can now emit an Objective-C resilient class stub instead. Also, when emitting an Objective-C category, reference the class stub if the class has resilient ancestry; previously this case would hit an assert. Note that class stubs always start with a zero word, with the address point pointing immediately after. This works around a linker issue, where the linker tries to coalesce categories and gets confused upon encountering a class stub.
…ns of classes with resilient ancestry Unless -enable-resilient-objc-class-stubs is passed in, these cases are not supported, so now we diagnose them instead of asserting or failing to link. Note the behavior change here; classes with resilient ancestry were previously isObjC(). However this is wrong since isObjC() means "statically visible to Objective-C via the generated header". After this patch, isObjC() only returns true for a class with resilient ancestry if -enable-resilient-objc-class-stubs is passed in.
Without -enable-resilient-objc-class-stubs, don't print classes with resilient ancestry at all, since they're not actually visible to Clang and referencing one will not actually work. When the flag is specified, such classes do appear in the generated header with the new objc_class_stub Clang attribute.
|
@swift-ci Please test |
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.1 cherry pick of #23320.
rdar://problem/45647064