-
Notifications
You must be signed in to change notification settings - Fork 10.5k
Import Forward Declared Objective-C Interfaces and Protocols #61606
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 smoke test |
@swift-ci Please Test Source Compatibility |
a4f5ac0
to
8037f87
Compare
@swift-ci Please Test Source Compatibility |
8037f87
to
318da9d
Compare
@swift-ci Please test |
@swift-ci Please Test Source Compatibility |
150fef5
to
9410ca3
Compare
@swift-ci Please Test Source Compatibility |
@swift-ci Please test |
9410ca3
to
f8423f6
Compare
@swift-ci Please test |
f8423f6
to
1a93949
Compare
@swift-ci Please test |
@swift-ci Please Test Source Compatibility |
@swift-ci Please Test Source Compatibility |
2 similar comments
@swift-ci Please Test Source Compatibility |
@swift-ci Please Test Source Compatibility |
1a93949
to
c68ffdf
Compare
@swift-ci please test |
@swift-ci Please Test Source Compatibility |
c68ffdf
to
573b7a9
Compare
@swift-ci please test |
@swift-ci please test source compatibility |
573b7a9
to
f8e8e42
Compare
@swift-ci please smoke test |
@swift-ci please test source compatibility |
@swift-ci Please test |
@swift-ci Please test source compatibility |
@beccadax When you get a chance, I've updated the PR with the diagnostic you suggested. |
Source compat passes with the flag on: #62649. Stress test fails, but other jobs are failing in the same way, seems unrelated. The Windows test here isn't really pending, it finished successfully: https://ci-external.swift.org/job/swift-PR-windows/8806/ |
@swift-ci Please test windows platform |
@beccadax Could I get a re-review here? Thanks |
Hi everyone, I wanted to draw attention to two aspects of this implementation that maybe were not entirely clear.
Tony's reply to my concern:
I'm not trying to advocate for forward declaring Swift types as a supported practice, but I do want to call out that I think this breakage can occur in practice. Firstly, Clang module B is usable by Objective-C clients without issue, and anecdotally that is where we run into most forward declaration issues (ie. only Objective-C clients used the interface before and had no problems with forward declarations, then a Swift client arrives and has problems). Even if clients shouldn't expect it to work, unfortunately it has worked for a long time, so I don't think its unlikely for clients to have working code on the ground doing this. If Swift module C imports only Clang module B, after this patch the APIs will work, since the compiler thinks the forward declarations refer to Clang definitions. It will only break once Swift module A is imported. So it is possible a Swift client starts using a Clang module that forward declares Swift types, and everything works for some time until they import the complete definition of that type. That said, I'm not overly worried about this since I think its relatively uncommon and easy to fix. I'm comfortable with both these caveats, and I don't see a better solution, but I wanted to make them explicit for others so that there are no surprises down the line. |
} | ||
} | ||
|
||
for (Decl *decl : topLevelObjCExposedDeclsInFileUnit) { |
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.
Could Decl *decl
be const Decl *decl
here?
I looked over the patch once myself and once with Nuri. Overall this PR looks good to me, and the set of included test cases looks very goods. However I am not the code owner, could Nuri please get a re-review for this PR please? Thanks |
6faffd2
to
cf7cbae
Compare
@swift-ci Please test |
With the Swift 5.9 branch cut quickly approaching on March 20th, we'd like to merge this in time for the release. The implementation hasn't changed for a month and if no new concerns arise, I intend on merging in the next week. If concerns crop up afterwards, I'll be available to fix them. That said, @DougGregor it seems you are the 5.9 release manager for the Swift compiler. If you have the time, I'd appreciate a review; an approval from the Apple side before merging would be preferred. |
This modifies the ClangImporter to introduce an opaque placeholder representation for forward declared Objective-C interfaces and protocols when imported into Swift. In the compiler, the new functionality is hidden behind a frontend flag -enable-import-objc-forward-declarations, and is on by default for language mode >6. The feature is disabled entirely in LLDB expression evaluation / Swift REPL, regardless of language version.
cf7cbae
to
86c5698
Compare
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.
I did a quick review (not very in-depth) and this looks good to me. I think it would still be good to get an in depth review from Becca, but I understand that she might not have time.
Please make sure to run the source compatibility test suite before landing this.
@swift-ci Please test |
@swift-ci Please test source compatibility |
2 similar comments
@swift-ci Please test source compatibility |
@swift-ci Please test source compatibility |
This patch modifies the ClangImporter to synthesize a placeholder for forward declared Objective-C interfaces and Protocols.
This is the implementation for SE-0384