Prior to the removal of the “lookup conformance function”, whenever
the type checker created a GenericSignatureBuilder, its lookup conformance
function would mark any referenced conformance as “used”. Do so now via
a LazyResolver callback, which fixes a regression in multi-file type
checking scenarios.
Now that the GenericSignatureBuilder is no longer sensitive to the input
module, stop uniquing the canonical GSBs based on that module. The main
win here is when deserializing a generic environment: we would end up
creating a canonical GSB in the module we deserialized and another
canonical GSB in the module in which it is used.
Implement a module-agnostic conformance lookup operation within the GSB
itself, so it does not need to be supplied by the code constructing the
generic signature builder. This makes the generic signature builder
(closer to) being module-agnostic.
Now that we pass in the correct type metadata for 'Self', it is
sound for a class to conform to a protocol with a default implementation
for a method returning 'Self'.
Fixes <rdar://problem/23671426>.
Consider the following code:
protocol P {
func foo<A>(_: A)
}
extension P {
func foo<A>(_: A) {}
}
class C<T> : P {}
Before, the witness thunk for [C : P].foo() had the generic signature
<T, A>, and the witness P.foo() was called with a substitution
Self := C<T>.
This is incorrect because the caller might be using a subclass of C
as the 'Self' type, but this was being erased.
Now, the witness thunk for [C : P].foo() has the generic signature
<X : C<T>, T, A>, and the witness P.foo() is called with the
substitution Self := X.
Fixes <rdar://problem/33690383>, <https://bugs.swift.org/browse/SR-617>.
At this point, we already have a witness, so the requirement
environment can depend on the witness as well as the requirement.
Then, store the RequirementEnvironment inside the RequirementMatch.
As part of type witness inference, allow us to infer a generic parameter
as the type witness for an associated type, when the associated type has
the same name as the generic parameter.
We likely want the more-general rule that generic parameters are always
visible as members of their enclosing type, but I'll tackle that separately.
This works around an order dependency that affected the source
compatibility suite.
Now that we pass in the correct type metadata for 'Self', it is
sound for a class to conform to a protocol with a default implementation
for a method returning 'Self'.
Fixes <rdar://problem/23671426>.
Consider the following code:
protocol P {
func foo<A>(_: A)
}
extension P {
func foo<A>(_: A) {}
}
class C<T> : P {}
Before, the witness thunk for [C : P].foo() had the generic signature
<T, A>, and the witness P.foo() was called with a substitution
Self := C<T>.
This is incorrect because the caller might be using a subclass of C
as the 'Self' type, but this was being erased.
Now, the witness thunk for [C : P].foo() has the generic signature
<X : C<T>, T, A>, and the witness P.foo() is called with the
substitution Self := X.
Fixes <rdar://problem/33690383>, <https://bugs.swift.org/browse/SR-617>.
At this point, we already have a witness, so the requirement
environment can depend on the witness as well as the requirement.
Then, store the RequirementEnvironment inside the RequirementMatch.
Follow-up to my earlier changes to drop 'inout' types when cloning parameter
lists, we also need to deal with substitutions into those parameter types.
This is an artifact of us having mostly---but not entirely---removed
InOutType from the AST. Fixes rdar://problem/34818336.
If unqualified name lookup finds an associated type, but resolution to
the type witness fails, produce a diagnostic rather than silently
failing. Fixes the crash in SR-5825, SR-5881, and SR-5905.
It's conceivable that we could resolve this with suitably global
associated type inference... but that's far off and it's best not to
crash until then.
Presence of some constraints (Subtype at least) requires a certain
contextual ranking of the type variables associated with them when
it comes to picking bindings, otherwise it might lead to no or
invalid solutions, because only a set of the bindings for the best
type variable is attempted.
Resolves: rdar://problem/22898292
