mirror of
https://github.com/apple/swift.git
synced 2025-12-21 12:14:44 +01:00
2bd850c56f
We shouldn't generate NestedTypeNameMatch same-type constraints between associated types we haven't realized yet. Otherwise, since maybeResolveEquivalenceClass() can call lookupNestedType() before looking up a PotentialArchetype, it is possible that maybeResolveEquivalenceClass() will return the newly-realized type even when resolutionKind is AlreadyKnown. This can cause an infinite recursion in expandConformanceRequirement(). However, we don't really have to do this here at all, because if a PotentialArchetype is registered with the same name later, we will introduce the same-type constraint in addedNestedType(). It suffices for lookupNestedType() to return the best associated type anchor and ignore the rest. Fixes https://bugs.swift.org/browse/SR-14289 / rdar://problem/74876047.
16 lines
272 B
Swift
16 lines
272 B
Swift
// RUN: %target-swift-frontend -emit-ir %s
|
|
|
|
public protocol One {
|
|
associatedtype MyType
|
|
}
|
|
|
|
public protocol Two {
|
|
associatedtype MyType
|
|
}
|
|
|
|
public protocol Three: One, Two where MyType: Three {}
|
|
|
|
extension Three {
|
|
public func doStuff(_: MyType.MyType.MyType) {}
|
|
}
|