Always desugar the base type of an extension when serializing. #6336
Conversation
|
@swift-ci Please test |
|
Filed SR-3443 for follow-up on this some day, mostly just to have a place to dup issues to (since it's a sort of regression). |
|
@swift-ci Please test |
|
Build failed |
|
Timeout? @swift-ci Please test Linux |
|
@shahmishal Linux builders can't seem to fetch from GitHub? https://ci.swift.org/job/swift-PR-Linux/4775/ |
|
Build failed |
|
@swift-ci Please test Linux |
|
Build failed |
This "fixes" two issues: - The name of a non-public typealias would leak into the public interface if the extension had any public members. - A common pattern of defining a platform-specific typealias for an imported class and then extending that type would lead to circularity when trying to deserialize the typealias. We /shouldn't/ be loading the extension at that point, but fixing that would be much harder. The "right" answer is to (a) check that the typealias is public if the extension has any public members, and (b) somehow ensure there is no circularity issue (either by not importing the extension as a result of importing the typealias, or by the extension being able to set its sugared base type later). rdar://problem/29694978
jrose-apple
force-pushed
the
canonicalize-extension-base-types
branch
from
b402ec8
to
7c633f7
Compare
|
@swift-ci Please test Linux |
|
@swift-ci Please smoke test macOS |
|
@swift-ci Please test Linux |
…#6336) This "fixes" two issues: - The name of a non-public typealias would leak into the public interface if the extension had any public members. - A common pattern of defining a platform-specific typealias for an imported class and then extending that type would lead to circularity when trying to deserialize the typealias. We /shouldn't/ be loading the extension at that point, but fixing that would be much harder. The "right" answer is to (a) check that the typealias is public if the extension has any public members, and (b) somehow ensure there is no circularity issue (either by not importing the extension as a result of importing the typealias, or by the extension being able to set its sugared base type later). rdar://problem/29694978
This sounds like network issue on Github servers. |
This "fixes" two issues:
The name of a non-public typealias would leak into the public interface if the extension had any public members.
A common pattern of defining a platform-specific typealias for an imported class and then extending that type would lead to circularity when trying to deserialize the typealias. We shouldn't be loading the extension at that point, but fixing that would be much harder.
The "right" answer is to (a) check that the typealias is public if the extension has any public members, and (b) somehow ensure there is no circularity issue (either by not importing the extension as a result of importing the typealias, or by the extension being able to set its sugared base type later).
rdar://problem/29694978