If you have a pair of requirements T : P and T == G<U>, the conformance
G : P might be conditional, imposing arbitrary requirements on U.
In particular, these conditional requirements can mention arbitrary
protocols on the right hand side.
Introducing these conformance requirements during property map construction
is totally fine when building a top-level generic signature, but when
building a protocol requirement signature, things get a bit tricky.
Because of the design of the requirement machine, it is better if the set
of protocols appearing on the right hand side of conformance requirements
in another protocol (the "protocol dependencies") are known *before* we
start building the requirement signature, because we build the requirement
signatures of all protocols in a connected component of this graph
simultaneously.
Introducing conformance requirements to hithero-unseen protocols after
the graph of connected components had already been built would require
mutating it in a tricky way, and possibly merging connected components.
I didn't find any examples of protocols that rely on conditional
requirement inference in our test suite, or in the source compatibility
suite.
So for now, I'm going to try to disable this feature inside protocols.
Another argument in favor of not doing conditional requirement
inference in protocols is that we don't do the ordinary kind of requirement
inference there either. That is, the following is an error:
protocol P {
associatedtype T == Set<U>
associatedtype U
}
Unlike with an ordinary top-level generic signature, we don't infer
'U : Hashable' here. So arguably the current behavior of protocols inferring
these requirements in the case of a conditional conformance only is also
rather odd.
For SIL substituted generic signature construction to work, we must
perform this step if either the conformance requirement or the
concrete type requirement is explicit. Previously, we only did it
if the concrete type requirement was explicit.
This is still somewhat unprincipled and I need to think about it
some more before porting it over to the requirement machine.
Fixes https://bugs.swift.org/browse/SR-15254 / rdar://problem/84827656.
