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.
The SDK build version is a decent heuristic for expected changes in the
SDK. Any change in SDK, to clang headers in particular, can break
references from cached swiftmodules.
Track the SDK build version as part of the swiftmodule cache hash. This
will ensure we rebuild from swiftinterfaces on SDK updates.
rdar://122655978
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.
An `@_export public import` is meaningful on it's own as it declares a
relationship between two modules and how clients see them. As such that
import doesn't have to be referenced from API to be appropriate. Let's
not warn on any public import with an `@_export` attribute.
rdar://122032960
The interface files were still printing inverses on the invertible
protocols, when that's not required. Doing so yielded warnings during
the build because `~Escapable` isn't yet ready for appearing in the
stdlib.
We want extensions to introduce default Copyable/Escapable just like
other generic contexts, so that once Optional adopts ~Copyable,
an `extension Optional` actually adds `Wrapped: Copyable` by default.
The old TypeAttributes reprsentation wasn't too bad for a small number of
simple attributes. Unfortunately, the number of attributes has grown over
the years by quite a bit, which makes TypeAttributes fairly bulky even at
just a single SourceLoc per attribute. The bigger problem is that we want
to carry more information than that on some of these attributes, which is
all super ad hoc and awkward. And given that we want to do some things
for each attribute we see, like diagnosing unapplied attributes, the linear
data structure does require a fair amount of extra work.
I switched around the checking logic quite a bit in order to try to fit in
with the new representation better. The most significant change here is the
change to how we handle implicit noescape, where now we're passing the
escaping attribute's presence down in the context instead of resetting the
context anytime we see any attributes at all. This should be cleaner overall.
The source range changes around some of the @escaping checking is really a
sort of bugfix --- the existing code was really jumping from the @ sign
all the way past the autoclosure keyword in a way that I'm not sure always
works and is definitely a little unintentional-feeling.
I tried to make the parser logic more consistent around recognizing these
parameter specifiers; it seems better now, at least.
Suppress warnings/errors when actor isolated synchroneous witness
is matched against `@preconcurrency` conformance requirement.
Witness thunk assumes isolation of the witness but instead of a
hop to its executor it would emit a runtime check to make sure
that its always called from the expected context.