Historically, we've allowed protocol requirements to be written with
`@_spi_available` which makes them unavailable to clients of the public
`.swiftinterface`. Don't diagnose this when checking a `.swiftinterface` since
there's nothing the client can do about it.
Resolves rdar://146334181.
Prior to the introduction of noncopyable generics, a ProtocolCompositionType
was 'simple' if it was exactly 'Any' or 'AnyObject'. Now, there is a new
simple case, where we have a single inverse requirement '~Copyable' or
'~Escapable', and the old logic was never updated to account for this
possibility. Instead, it would ignore inverses, so it would claim that
a composition like `P & ~Copyable` was simple when it shouldn't be.
Fixes rdar://139465298.
If an enum comes from a different module that has `ExtensibleEnums`
feature enabled, unless it requires either `@unknown default:` or
`@frozen` because it is allowed to introduce new cases in the future
versions of the module.
Most SDKs use only swiftinterfaces under usr/lib/swift. Let's make sure
we standardize this behavior and use only swiftinterface when they are
present, even if there are also binary swiftmodule files available.
Apply the same logic to SubFrameworks as well while we're at it.
rdar://145316821
In a swiftinterface a declaration could be unavailable because it was written
in source with an `@_spi_available` attribute so it isn't possible to safely
reject unavailable stored properties in that context.
Resolves rdar://144958440.
This flag is unsafe since the compiler does not verify that the resulting
public interface will compile with the module import removed. The modern
alternative to this flag is `@_spiOnly import`. Since the flag is no longer
used by any projects it should be removed.
Resolves rdar://134351088.
Instead of requested action. In implicit builds, implicit interface build sub-invocations inherit their parent invocation's requested action, which the code was failing to detect that we were building an interface, not source, and erroneously resulted in enabling in-package module dependency resolution.
Resolves rdar://143505814
As specified by the SE-0446 acceptance, extensions that declare a type's
conditional `Copyable` or `Escapable` ability must reiterate explicitly all
of the `Copyable` and/or `Escapable` requirements, whether required or not
required (by e.g. `~Copyable`) that were suppressed in the original
type declaration.
Diagnostics are suppressed when parsing swiftinterface files, since the
warnings emitted from compiling the swiftinterface of a dependency would just
be a nuisance. It follows that warnings generated when parsing the arguments in
a swiftinterface file should also be suppressed, but that wasn't happening
because the diagnostic engine of the main compile was used for parsing. Pass
the diagnostic engine of the compiler subinstance instead, and proactively
suppress warnings before parsing begins.
Resolves rdar://142814164.
Types annotated as `@_addressableForDependencies` are still usable by older
compilers that don't know about nonescapable types or lifetime dependencies,
since it only affects the behavior of the type when it's the source of a
dependency.
It was difficult to preserve the existing, buggy behavior of availability
attribute inference with respect to attributes specifying availability for
non-platform-specific domains. Instead, this change improves attribute merging
by tracking every domain independently, and only merging attributes from the
same domain.
A `@backDeployed` function printed in a `.swiftinterface` must have a function
body so that SILGen can emit a fallback copy to call when the back deployed
function is unavailable. Previously, the compiler would crash in SILGen when
compiling an interface containing a back deployed function without a body.
Resolves rdar://141593108.
A `@backDeployed` function printed in a `.swiftinterface` must have a function
body so that SILGen can emit a fallback copy to call when the back deployed
function is unavailable. Previously, the compiler would crash in SILGen when
compiling an interface containing a back deployed function without a body.
Resolves rdar://141593108.
When serializing the module interface path of an interface that
is part of the SDK, we serialize relative to the SDK path. During
deserialization we need to know if a path was serialized relative
to the SDK or not. The existing logic assumes any relative path
has been serialized relative to the SDK, which makes it impossible
to compile modules from relative swiftinterface paths that are not
part of the SDK.
Update the swiftmodule file to include an attribute to show if the
path was serialized relative to the SDK or not, which is used
during deserialization to correctly reconstruct the interface path.
When compiling the swiftmodule from the textual swift interface, ensure
that we re-serialise the static or dynamic nature of the module. This is
required for proper code generation where the static and dynamic linking
is material to symbolic references. This also opens the possibility of
optimizations on other platforms via internalisation of the symbols.
Fixes: #77756
Type annotations for instruction operands are omitted, e.g.
```
%3 = struct $S(%1, %2)
```
Operand types are redundant anyway and were only used for sanity checking in the SIL parser.
But: operand types _are_ printed if the definition of the operand value was not printed yet.
This happens:
* if the block with the definition appears after the block where the operand's instruction is located
* if a block or instruction is printed in isolation, e.g. in a debugger
The old behavior can be restored with `-Xllvm -sil-print-types`.
This option is added to many existing test files which check for operand types in their check-lines.
