Hack: Force UIEdgeInsets.zero to always come from the SDK #17122
Conversation
|
@swift-ci Please test |
|
@swift-ci Please test source compatibility |
|
Build failed |
|
Build failed |
jrose-apple
force-pushed
the
UIEdgeInsetsZero
branch
from
b4d95c8
to
8a8adf7
Compare
|
Let's try that again. @swift-ci Please test |
|
@swift-ci Please test source compatibility |
|
Build failed |
|
Build failed |
|
@swift-ci Please test source compatibility |
|
|
||
| import UIKit | ||
|
|
||
| _ = UIEdgeInsets.zero |
There was a problem hiding this comment.
Can you try defining default arguments with these values as well so that we can test serializing references to these globals too?
There was a problem hiding this comment.
Good call. The original bug showed up just a mention of the SIL global in the partial swiftmodules, but having an actual reference to it is important.
|
@jrose-apple I'm curious why XREFs to imported types don't respect the module filter. This would have fixed the problem without adding a special case. |
|
That doesn't actually fix the problem, because we don't want to find the one in the overlay. We want the one in the actual Clang module. (The original motivation, though, was when we thought swiftmodule was going to be a stable format, in which case it needs to cope with declarations being moved from one framework to another, something that's legal in Objective-C.) |
...instead of relying on the one in the overlay in pre-4.2 versions of Swift. This caused crashes in deserialization, which (deliberately) doesn't respect availability. There are three changes here: - Remove UIEdgeInsets.zero and UIOffset.zero from the UIKit overlay. - Always use the 4.2 name for UIEdgeInsetsZero and UIOffsetZero from the underlying UIKit framework. (This is the nested name.) - Ignore the unavailability messages for those two constants in pre-4.2 Swift, since we're now relying on them being present. The latter two, the compiler changes, can go away once UIKit's API notes no longer specify different pre-4.2 behavior, but meanwhile we need to keep compatibility with the SDKs released in Xcode 10b1. https://bugs.swift.org/browse/SR-7879
jrose-apple
force-pushed
the
UIEdgeInsetsZero
branch
from
8a8adf7
to
a467bea
Compare
|
@swift-ci Please test |
|
Build failed |
|
Build failed |
|
@swift-ci Please smoke test Linux |
...instead of relying on the one in the overlay in pre-4.2 versions of Swift. This caused crashes in deserialization, which (deliberately) doesn't respect availability. There are three changes here: - Remove UIEdgeInsets.zero and UIOffset.zero from the UIKit overlay. - Always use the 4.2 name for UIEdgeInsetsZero and UIOffsetZero from the underlying UIKit framework. (This is the nested name.) - Ignore the unavailability messages for those two constants in pre-4.2 Swift, since we're now relying on them being present. The latter two, the compiler changes, can go away once UIKit's API notes no longer specify different pre-4.2 behavior, but meanwhile we need to keep compatibility with the SDKs released in Xcode 10b1. https://bugs.swift.org/browse/SR-7879 (cherry picked from commit a6ae2d7)
...instead of relying on the one in the overlay in pre-4.2 versions of Swift. This caused crashes in deserialization, which (deliberately) doesn't respect availability. There are three changes here: - Remove UIEdgeInsets.zero and UIOffset.zero from the UIKit overlay. - Always use the 4.2 name for UIEdgeInsetsZero and UIOffsetZero from the underlying UIKit framework. (This is the nested name.) - Ignore the unavailability messages for those two constants in pre-4.2 Swift, since we're now relying on them being present. The latter two, the compiler changes, can go away once UIKit's API notes no longer specify different pre-4.2 behavior, but meanwhile we need to keep compatibility with the SDKs released in Xcode 10b1. https://bugs.swift.org/browse/SR-7879 (cherry picked from commit a6ae2d7)
...instead of relying on the one in the overlay in pre-4.2 versions of Swift. This caused crashes in deserialization, which (deliberately) doesn't respect availability.
There are three changes here:
UIEdgeInsets.zeroandUIOffset.zerofrom the UIKit overlay.UIEdgeInsetsZeroandUIOffsetZerofrom the underlying UIKit framework. (This is the nested name.)The latter two, the compiler changes, can go away once UIKit's API notes no longer specify different pre-4.2 behavior, but meanwhile we need to keep compatibility with the SDKs released in Xcode 10b1.
SR-7879 / rdar://problem/40735990