You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have read CONTRIBUTING and have done my best to follow them.
What did you do?
I'm integrating Quick into a codebase where I need to define the Xcode module/framework manually. As part of that, I'm roughly following the .podspec to produce results. Part of this investigation yielded an issue: I couldn't get the Quick Objective-C files to be able to see the World class from Swift.
This is because internal Swift classes are not accessible, even within the same module:
Because the generated header is part of the framework’s public interface, only declarations marked with the public or open modifier appear in the generated header for a framework target. Methods and properties that are marked with the internal modifier and declared within a class that inherits from an Objective-C class are accessible to the Objective-C runtime.
Your reaction might be: but clearly Quick is doing that right now, and it compiles fine!
It took me all day, but I finally narrowed down the "why": Quick is asking for extension-only API which exposes an underlying bug in the compiler which causes internal Swift things to be available in the Quick-Swift.h file.
You can reproduce this issue by disabling the extension-only flag in the Xcode project (set APPLICATION_EXTENSION_API_ONLY to NO) and it'll stop compiling, unable to find World:
…/Sources/QuickObjectiveC/QuickSpec.m:30:27: Use of undeclared identifier 'World'; did you mean 'bold'?
I recommend you take a look at how the bridging is working here so that you're not stuck scrambling to get this to work once the underlying bug is resolved. You can likely use the fact that internal properties and methods are still available to get the kind of segregation you're looking for.
You need to pass -application-extension down to the Swift compiler in order to get this bug to happen (and make it compile). I can't tell you the Bazel specifics, though it's likely similar, but in Buck this looks like:
What did you do?
I'm integrating Quick into a codebase where I need to define the Xcode module/framework manually. As part of that, I'm roughly following the
.podspec
to produce results. Part of this investigation yielded an issue: I couldn't get the Quick Objective-C files to be able to see theWorld
class from Swift.This is because
internal
Swift classes are not accessible, even within the same module:Your reaction might be: but clearly Quick is doing that right now, and it compiles fine!
It took me all day, but I finally narrowed down the "why": Quick is asking for extension-only API which exposes an underlying bug in the compiler which causes internal Swift things to be available in the
Quick-Swift.h
file.You can reproduce this issue by disabling the extension-only flag in the Xcode project (set
APPLICATION_EXTENSION_API_ONLY
toNO
) and it'll stop compiling, unable to findWorld
:I recommend you take a look at how the bridging is working here so that you're not stuck scrambling to get this to work once the underlying bug is resolved. You can likely use the fact that internal properties and methods are still available to get the kind of segregation you're looking for.
Environment
List the software versions you're using:
The text was updated successfully, but these errors were encountered: