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.
Suppressing this feature doesn't disable the use of new syntax in the
normal way. Instead, it introduces `@rethrows` on the
AsyncIteratorProtocol and AsyncSequence protocols, so that older
compilers can still use the async sequences generated by newer
compilers and standard libraries.
Fixes the rest of rdar://123782658
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.
Due to the mapping of iOS platform availability to tvOS platform availability,
we were ending up inferring an availability attribute `@available(tvOS)` for
an associated type, which does not parse properly. Suppress the creation
of inferred availability attributes when they convey no information
(e.g., because they have no introduced/deprecated/obsoleted/etc. in them).
Fixes rdar://123545422.
The Swift compiler can load either the binary swiftmodule file or the
textual swiftinterface file when importing a module. It currently picks
the swiftmodule over the swiftinterface, unless there’s an exception. We
should flip the default for distributed modules, prefer the
swiftinterface over the swiftmodule unless there’s an exception.
rdar://122955640
Functions that use typed throws _anywhere_ in their signature (including in
closure types) need to be surrounded with `if $TypedThrows` guards in
swiftinterfaces.
Previously package decls at the defition sites were non-resilient.
Now they are resilient by default and are printed in interface as so.
Ref: rdar://118461385
Nested types with inverse requirements on generic parameters would
sometimes print incorrectly. We only print the inverses on outer generic
parameters for extensions.
fixes rdar://123281976
Since we no longer remove these attributes from the AttributedTypeRepr,
if we print based on the TypeRepr, we'll print them twice. The best
solution is to only print the attributes based on the inheritance clause
if we're not printing the type based on the TypeRepr.
Fixes rdar://122965951.
When a NoncopyableGenericsMismatch happens between the compiler and
stdlib, allow the compiler to rebuild the stdlib from its interface
instead of exiting with an error.
The "#if compiler(>=5.3) && $AsyncAwait" checks were necessary for
staging in concurrency in Swift 5.5. At this point, it's safe to assume
that any compiler that tries to read a generated Swift interface file will
support concurrency, so we can stop emitting these guards.
