When substituting a type like T.A.B where A and B are
associated types and the conformance requirement on T.A
is implied by conformance requirements on T, we would
crash.
The problem is that we have no way of representing an
abstract conformance with nested concrete types.
This patch adds a workaround that we can live with until
ConformanceAccessPaths are plumbed through all the way.
Fixes <rdar://problem/30737546> and
<https://bugs.swift.org/browse/SR-3500>.
Possibly fixes <rdar://problem/31334245>.
This test was passing for the wrong reasons before. We need to
correctly model cases where a nested type of an abstract conformance is
in fact concrete and, therefore, has concrete conformances. XFAIL for now.
Fixes assertion failures in SILGen and the optimizer with this
exotic setup:
protocol P {
associatedtype T : Q
}
protocol Q {
func requirement<U : P>(u: U) where U.T == Self
}
Here, we only have a U : P conformance, and not Self : Q,
because Self : Q is available as U.T : Q.
There were three problems here:
- The SIL verifier was too strict in verifying the generic signature.
All that matters is we can get the Self parameter conformance, not
that it's the first requirement, etc.
- GenericSignature::getSubstitutionMap() had a TODO concerning handling
of same-type constraints -- this is the first test-case I've found
that triggered the problem.
- GenericEnvironment::getSubstitutionMap() incorrectly ignored
same-type constraints where one of the two types was a generic
parameter.
Fixes <https://bugs.swift.org/browse/SR-3321>.
