[Serialization] Allow unbound generic types to cross-reference typealias decls #16784
Conversation
…ias decls Ideally `UnboundGenericType` should never be serialized but it is currently allowed to make generic `typealias` declarations without specifying generic parameters, so it should be allowed to cross reference typealias decls in such types as well because `NameAliasType` can't be used until generic parameters are resolved. This is only a temporary fix and more comprehensive solution is still pending here, most likely such declarations should not produce `UnboundGenericType` but instead should copy generic parameters from underlying type and produce proper `NameAliasType`. Resolves: rdar://problem/37384120
There was a problem hiding this comment.
Hm. The original logic to always go through NameAliasType was intended to make sure a typealias that failed to import could always be replaced by its underlying type. But the logic for serialization recovery already isn't very strong for generic types, and this wouldn't be a regression because it's just doing what a no-asserts build would do anyway. Okay, we can take this.
|
Ah yes, this is an annoying corner case. I agree we should “desugar” such type aliases early instead of forming UnboundGenericType as a long term fix. It’s only on accident that this construct was even accepted at all, but now we’re stuck with it. |
|
@swift-ci please test |
|
@swift-ci please test source compatibility |
|
We might be able to stage out this construct, but regardless... we need to fix the modeling problem at some point. |
Ideally
UnboundGenericTypeshould never be serialized but it iscurrently allowed to make generic
typealiasdeclarations withoutspecifying generic parameters, so it should be allowed to cross
reference typealias decls in such types as well because
NameAliasTypecan't be used until generic parameters are resolved.
This is only a temporary fix and more comprehensive solution is still
pending here, most likely such declarations should not produce
UnboundGenericTypebut instead should copy generic parameters fromunderlying type and produce proper
NameAliasType.Resolves: rdar://problem/37384120