-
Notifications
You must be signed in to change notification settings - Fork 309
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
If compiled as an xcframework, the package produces a non-compiling swiftinterface file #157
Comments
I have attached a test XCode project that demonstrates the issue: |
This problem propagates to other frameworks that use this one as a dependency. |
I have discovered that if I simply comment out the typealias defined in the UnorderedView and then fix the line where it is used: OrderedSet+UnorderedView.swift, line 305 Then the resulting .swiftinterface file compiles again. Note: I tried it with Xcode 13.3 and 14 beta 5. |
I have created FB11262423 against the Swift compiler. |
in my tests, it seems that commenting out the |
This is one bizarre issue -- something smells fishy in the name lookup department. It's evidently triggered by the fully qualified names in the .swiftinterface file. // Original:
extension OrderedSet {
@frozen
public struct UnorderedView {
public typealias Element = OrderedSet.Element
...
}
}
// Generated .swiftinterface:
extension OrderedCollections.OrderedSet {
@frozen public struct UnorderedView {
public typealias Element = OrderedCollections.OrderedSet<Element>.Element
// 🚫 error: Type alias 'Element' references itself
...
}
} The name lookup rules are quite wacky, but I think the issue is that the #162 works around this problem by moving the typealias declaration into an extension. This results in the following code in the .swiftinterface: extension OrderedCollections.OrderedSet.UnorderedView : Swift.SetAlgebra {
public typealias Element = OrderedCollections.OrderedSet<Element>.Element
} (Don't ask me why/how this is different -- let's see where the compiler bug leads us. 🙈) |
(Obligatory note: this package does not promise any level of ABI stability -- all modules importing xcframeworks generated from this code must be rebuilt whenever the xcframework is updated. This package was not designed to be built with library evolution enabled, and it is not optimized for that dialect of Swift. However, such builds still ought to work, and these bug reports are very welcome!) |
Information
Checklist
main
branch of this package.Steps to Reproduce
I used the following:
swift create-xcframework OrderedCollections --configuration debug --stack-evolution --platform ios --xc-setting CLANG_ENABLE_CODE_COVERAGE=NO --xc-setting GCC_INSTRUMENT_PROGRAM_FLOW_ARCS=NO --xc-setting SWIFT_SERIALIZE_DEBUGGING_OPTIONS=NO --xc-setting OTHER_SWIFT_FLAGS="-Xfrontend -no-serialize-debugging-options" --xc-setting DEBUG_INFORMATION_FORMAT=dwarf-with-dsym
(Please also add the xcframework to Build Phases -> Link Binary with Libraries)
Expected behavior
The app must compile without errors.
Actual behavior
Compiler gives errors in the swiftinterface file of the xcframework:
The text was updated successfully, but these errors were encountered: