Exempt Swift Interface Files From Whole-Module ObjC Errors #34652
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
We don't expect swiftinterface files to have anything meaningful to report from these checks anyhow - they will have been run at module generation time anyways. In fact, the linked radar demonstrates how this kind of checking can be detrimental to the usability of the compiler. The test committed here declares the CoreFeatures framework, an Objective-c (root) class and a set of Objective-C protocols. Now for the fun part: The Objective-C class is made to conform to the Objective-C protocols in a Swift extension. This extension is then printed into the generated CoreFeatures-Swift header and made available to clients of the module. Now, because we have an Objective-C protocol and a base class that is imported from Objective-C, we mirror-in the members of RootProtocol. The sum total of the monster we have built is that we now have a Swift class that implements some requirements, and an Objective-C protocol that has requirements mirrored into that same class. The result is a raft of spurious selector conflict diagnostics that the user cannot work around unless they own both the class and the protocol. Exempt swiftinterface files from this checking. rdar://69550935
Contributor
Author
|
@swift-ci test |
Contributor
Author
|
@swift-ci test source compatibility |
1 similar comment
Contributor
Author
|
@swift-ci test source compatibility |
Contributor
Author
|
⛵ |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
We don't expect swiftinterface files to have anything meaningful to
report from these checks anyhow - they will have been run at module
generation time anyways.
In fact, the linked radar demonstrates how this kind of checking can be
detrimental to the usability of the compiler. The test committed here
declares the CoreFeatures framework, an Objective-C (root) class and a
set of Objective-C protocols. Now for the fun part: The Objective-C
class is made to conform to the Objective-C protocols in a Swift
extension. This extension is then printed into the generated
CoreFeatures-Swift header and made available to clients of the module.
Now, because we have an Objective-C protocol and a base class that is
imported from Objective-C, we mirror-in the members of RootProtocol.
The sum total of the monster we have built is that we now have a Swift
class that implements some requirements, and an Objective-C protocol
that has requirements mirrored into that same class. The result is
a raft of spurious selector conflict diagnostics that the user cannot
work around unless they own both the class and the protocol.
Exempt swiftinterface files from this checking.
rdar://69550935