The type aliases for inferred type witnesses to the AsyncSequence and
AsyncIteratorProtocol's Failure associated type are getting in the way
of existing types with the same name. Therefore, when we create these
type aliases, given them weird names (e.g., `__AsyncSequence.Failure`) and
wire them up with `@_implements(<protocol>, Failure)` so that
associated type inference will find them.
This is probably a model we should move to in general, because it's odd
that we inject new declarations into types that could cause conflicts.
However, start by staging it in for just this one associated type
where we have source-compatibility concerns, and we can expand it over
time.
Fixes rdar://124362873.
The newly-introduced associated type `AsyncSequence.Failure` must
always be equivalent to the `Failure` type of the
`AsyncIteratorProtocol`. If the `AsyncSequence` type itself defines a
nested `Failure` type (say, for another purpose), associated type inference
would pick it and reject the `AsyncSequence`, causing a source compatibility
problem.
Work around the issue in two ways. First, always infer the type
witness for `AsyncSequence.Failure` from the type witness for
`AsyncIteratorProtocol.Failure`, so they can't be out of sync. This
means that we'll never even consider a nested `Failure` type in the
`AsyncSequence`-conforming type. This hack only applies prior to Swift 6.
Second, when we have inferred a `Failure` type and there is already
something else called `Failure` within that same nominal type, don't
print the inferred typelias into a module interface because it will
cause a conflict.
Fixes rdar://123543633.
Now that associated types can have availability, make sure that we
infer availability attributes for any inferred type witnesses of said
associated types based on both the enclosing context and the associated
type itself. This eliminates failures in the emitted Swift interfaces.
Fixes rdar://122596219.
