mirror of
https://github.com/apple/swift.git
synced 2025-12-14 20:36:38 +01:00
2a0c8d1090
The maybeResolveEquivalenceClass() method can deallocate equivalence classes, because it calls updateNestedTypeForConformance(), which calls addSameTypeRequirement(). Therefore, the EquivalenceClass stored inside a ResolvedType could become invalid across calls to maybeResolveEquivalenceClass(). This was a problem in one place in particular, when adding a new same-type constraint between two type parameters. Fix this by not caching the equivalence class of a PotentialArchetype in the ResolvedType implementation. The only time an equivalence class is now stored is when returning an unresolved type, which is acted upon immediately. Fixes <https://bugs.swift.org/browse/SR-12812>, <rdar://problem/63422600>.
20 lines
374 B
Swift
20 lines
374 B
Swift
// RUN: %target-swift-frontend -emit-ir %s
|
|
|
|
public protocol P1 {
|
|
associatedtype Value
|
|
}
|
|
|
|
public protocol P2 {
|
|
associatedtype Value
|
|
}
|
|
|
|
public class Class2<V> : P2 {
|
|
public typealias Value = V
|
|
}
|
|
|
|
public class Superclass<T1, T2> where T1 : P1, T2 : P2, T2.Value == T1.Value {
|
|
}
|
|
|
|
public class Subclass<T1, T2> : Superclass<T1, T2> where T1 : P1, T2 : Class2<T1.Value> {
|
|
}
|