Closed ZevEisenberg closed 3 years ago
1 Warning | |
---|---|
:warning: | Big PR |
2 Messages | |
---|---|
:book: | Test Results |
:book: | Code Coverage |
76.71%
Files changed | - | - |
---|---|---|
AdaptableTextContainer.swift | 42.00% |
:no_entry_sign: |
AdaptiveStyle.swift | 73.99% |
:warning: |
StyleableUIElement.swift | 74.62% |
:warning: |
Powered by xcov
Generated by :no_entry_sign: Danger
Hmmm, it looks like there's some weirdness with UIFontDescriptor.FeatureKey.type
and UIFontDescriptor.FeatureKey.selector
in terms of iOS version checking. I can't figure out what incarnation I need. I thought this would work, but it does not:
let BONFontFeatureTypeIdentifierKey: UIFontDescriptor.FeatureKey = {
if #available(iOS 10, macCatalyst 13, tvOS 10, watchOS 2, *) {
return .type
}
else {
return .featureIdentifier
}
}()
let BONFontFeatureSelectorIdentifierKey: UIFontDescriptor.FeatureKey = {
if #available(iOS 10, macCatalyst 13, tvOS 10, watchOS 2, *) {
return .selector
}
else {
return .typeIdentifier
}
}()
That builds in Xcode 13, but in Xcode 12 I get:
🛑 Type 'UIFontDescriptor.FeatureKey' has no member 'type'
Thanks @ZevEisenberg! Any further thoughts on why the availability check is not working as expected?
Nope. Not sure if bug or what. You might want to try reproing in a sample project, and then doing a WWDC lab or at least radar if you can't figure it out.
From my reading, it appears that the @available
checks for enum cases with associated values was originally broken, and they have 'resolved' it in Swift 5.5
https://github.com/apple/swift/pull/36327
The old behavior:
- Stored properties could not have @available at all.
- Enum elements with associated values could be @available without restriction.
When computing the in-memory layout of a type we require that all stored types are available at runtime, that is, not any newer than the intersection of the current deployment target and the availability context of their type.
This means that stored properties and enum elements with associated values must have the same availability checking behavior as each other, and also that both existing behaviors were wrong.
The new rule is that @available is only allowed on either kind of declaration if the OS version is not any newer than the enclosing availability context.
The easiest and most minimal solution might be to bump the minimum iOS version to 11.0 and remove the availability check, which I think I might prefer at this point.
I'm fine with that. Maybe do an audit for any other availability checks that can be removed. It'll need to be a major version bump because of semver
Any update on this? :)
Hi, is there any branch for BonMot that I can test my project on Xcode 13/iOS15 ?
Sorry folks, looks like we are blocked on known bug in Xcode 13b2, unless y'all can come up with a workaround: https://github.com/Rightpoint/BonMot/pull/411#discussion_r659075502
Fixes #409, but does not add Xcode 13 to the CI test runners because CircleCI doesn't support Xcode 13 yet.