-
Notifications
You must be signed in to change notification settings - Fork 10.4k
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
[SR-5221] Second generated header for the 'internal' parts of framework targets #47797
Comments
Not quite a StarterBug, but not out of the question for an external contributor who's already done a few StarterBugs. |
The PR in #29751 would address this, but it's not clear when we'll land it. |
Comment by Brian Boyle (JIRA) Just wanted to check if there is a chance this feature might be addressed in the near future? I notice the PR linked above was closed without being merged. Currently facing this issue of private Swift code in an XCFramework being publicly exposed because functions need to be marked private in order to be available to Objective-c code. |
Hello, do we have any updates on this? @beccadax . We have a similar use case for our SDK framework and its getting hard to interoperate inside our framework. The only option is to fully migrate to swift, but unfortunately that won't be possible for us at this stage. |
Some projects already use the internal class/methods of the Swift framework in their Objective-C code. Not sure if this behavior is expected. |
I discovered that passing |
Hi, just to see if this feature is still considered? It would be really helpful to get this as a feature for frameworks, instead of having manual scripts. Really interested in this one, especially now when Swift C++ interop is available. I would really like to help implement it. |
Is there any new info about this? |
Additional Detail from JIRA
md5: 9ba074083669e26a8ed45ebe1759e489
Issue Description:
To improve mixed Swift/Objective-C frameworks, there should be a way to generate a header for the
internal
parts of a Swift framework that are also@objc
. This would act like a "project" header in Xcode that does not get copied into the build products.This hasn't been implemented in the past mainly because it requires splitting the internal members of a public class out to a category, but support for "delaying" members got added last year in PR 4155 anyway. This would just be another form of that.
Implementing this would involve something like the following:
A new
-emit-objc-internal-header-path
command-line option.Rather than skipping over
internal
declarations in PrintAsObjC, adding them to a list much like thedelayedMembers
list today.Print all those declarations to a separate buffer, with a separate imports list.
Write all that to a new header that imports
<MyModule/MyModule-Swift.h>
.There are then Xcode-side changes that need to happen to make this a fully-supported feature, but this would be good enough to use it with a toolchain!
The text was updated successfully, but these errors were encountered: