mirror of
https://github.com/apple/swift.git
synced 2025-12-21 12:14:44 +01:00
4a019f0662
Returning a null GenericSignature is not the right way to break a cycle, because then callers have to be careful to handle the case of a null GenericSignature together with a non-null GenericParamList, for example in applyGenericArguments(). An even worse problem can occur when a GenericSignatureRequest for a nested generic declaration requests the signature of the parent context, which hits a cycle. In this case, we would build a signature where the first generic parameter did not have depth 0. This makes the requirement machine upset, so this patch implements a new strategy to break such cycles. Instead of returning a null GenericSignature, we build a signature with the correct generic parameters, but no requirements. The generic parameters can be computed just by traversing GenericParamLists, which does not trigger more GenericSignatureRequests, so this should be safe.
13 lines
478 B
Swift
13 lines
478 B
Swift
// RUN: %target-typecheck-verify-swift
|
|
|
|
struct Foo<T> {}
|
|
|
|
protocol P1 {
|
|
associatedtype A // expected-note {{protocol requires nested type 'A'; do you want to add it?}}
|
|
}
|
|
extension Foo: P1 where A : P1 {}
|
|
// expected-error@-1 {{extension of generic struct 'Foo' has self-referential generic requirements}}
|
|
// expected-note@-2 {{while resolving type 'A'}}
|
|
// expected-note@-3 {{through reference here}}
|
|
// expected-error@-4 {{type 'Foo<T>' does not conform to protocol 'P1'}}
|