For consistency with invertible protocols using `~Sendable` should
only prohibit use of unconditional extensions.
For example:
```swift
struct G<T>: ~Sendable {}
```
The following (unconditional) extension is rejected:
```
extension G: Sendable {} // error: cannot both conform to and suppress conformance to 'Sendable'
```
But conditional on `T` is accepted:
```
extension G: Sendable where T: Sendable {} // Ok!
```
When emitting module interfaces, parameterized protocols in inheritance clauses were being printed with generic arguments (public struct T: Fancy<Float64>), causing errors with protocol conformance verification.
The fix strip ParameterizedProtocolType to its base protocol type when printing inherited types, producing the correct inheritance clause.
Resolves: rdar://161925627
We have long switched to delegate the checking of whether a module is up-to-date to the build system (SwiftDriver) and stopped serializing file dependencies for interface-built binary modules.
Resolves rdar://162881032
`discard self` requires knowledge of the internal layout of the type in order to clean
up its fields while bypassing its public `deinit`. Inlinable code can get copied into
and run from outside of the defining module, so this is impossible to implement.
Fixes rdar://160815058.
.swiftinterface sometimes prints a pattern binding initializer and the
accessor block. However the parser doesn't expect such constructs and
the disambiguation from trailing closures would be fragile. To make it
reliable, introduce a disambiguation marker `@_accessorBlock` .
`ASTPrinter` prints it right after `{` only if 1) The accessor block is
for a pattern binding declaration, 2) the decl has an initializer
printed, and 3) the non-observer accessor block is being printed. In the
parser, if the block after an initializer starts with
`{ @_accessorBlock`, it's always parsed as an accessor block instead of
a trailing closure.
rdar://140943107
This one `DEPCHANGE-DAG: SDKDependencies.swift` used to match because
the expansion of the `%t` temp dir contained the substring
"SDKDependencies.swift", but this is now sanitized to `TMP_DIR`.
These are tests that fail in the next commit without this flag. This
does not add -verify-ignore-unrelated to all tests with -verify, only
the ones that would fail without it. This is NFC since this flag is
currently a no-op.
The intent for `@inline(always)` is to act as an optimization control.
The user can rely on inlining to happen or the compiler will emit an error
message.
Because function values can be dynamic (closures, protocol/class lookup)
this guarantee can only be upheld for direct function references.
In cases where the optimizer can resolve dynamic function values the
attribute shall be respected.
rdar://148608854
If we demangle the name but we can't resolve the opaque return
declaration, we would dereference a null pointer and crash.
Speculative fix for rdar://161067984.
We don't need to print the `@c @implementation` functions in
swiftinterfaces as clients need only to see the original declaration in
the C header. Don't print `@objc @implementation` functions either, but
still print simple `@c` and `@objc` functions.
Forgetting to handle DistributedActor next to Actor strikes again:
Actors are special that their conformance is implicit and needs not be
printed in swift interface files.
an actor's Actor conformance was filtered out, however the same logic
needs to be applied to DistributedActor, as otherwise there can be
redundant conformance errors when validating module interface files.
Resolves rdar://160252579
Limit reporting as an error imports of a non-library-evolution module
from a library-evolution enabled module to sources that are part of the
SDK. The error also requires having enabled `InternalImportsByDefault`.
This should help prevent SDK breaking regressions while loosening the
restriction elsewhere.
Framework owners can enable `-library-level api` or `spi` to get this
check as an error, along with more sanity checks.
Other cases remain as a warning. We should look to silence it in some
cases or offer a flag to do so.
rdar://160414667
If a .swiftinterface file does not include an explicit `-language-mode` option
(or its predecessor `-swift-version`) and needs to be built as a dependency of a
client compilation, then the invocation to build the module from interface
would end up inheriting the language mode that the client code is built with.
This can result in spurious type checking diagnostics or even mis-compilation.
To ensure that a module interface is always built using the language mode that
its source code was originally built with, require an explicit `-language-mode`
option when emitting swiftinterface files.
In https://github.com/swiftlang/swift/pull/84307 this diagnostic was downgraded
to a warning. The failures it caused in PR testing should now be resolved.
Resolves rdar://145168219.
When a module has been imported `@preconcurrency` in source, when it is printed
in a `swiftinterface` file it should be printed along with the attribute to
ensure that type checking of the module's public declarations behaves
consistently.
This fix is a little unsatisfying because it adds another a linear scan over
all imports in the source for each printed import. This should be improved, but
it can be done later.
Resolves rdar://136857313.
Downgrade the new error in https://github.com/swiftlang/swift/pull/84244 to a
warning.
The PR smoke test build is using a different build system that is failing to
pass `-swift-version` arguments when building various stdlib modules. That
needs to be fixed, but for now we also need to unblock CI.
This is the ASTPrinter change to go with the Sema change.
We now print @_opaqueReturnTypeOf using the new nested
syntax when parameter packs are involved.
Fixes rdar://problem/151171381.
We now allow the dummy identifier to be a qualified reference, so
that we can reconstruct generic parameter lists from multiple levels:
@_opaqueReturnTypeOf(...) __.<OuterArgs...>.__<InnerArgs...>
This fixes an ambiguity with parameter packs, where flattening the
packs from multiple levels of nested types no longer produced an
unambiguous result.
To maintain backward compatibility, we still accept the old "flat"
form when no parameter packs are present.
If a `.swiftinterface` file does not include an explicit `-language-mode`
option (or its predecessor `swift-version`) and needs to be built as a
dependency of a client compilation, then the invocation to build the module
from interface would end up inheriting the language mode that the client code
is built with. This can result in spurious type checking diagnostics or even
mis-compilation. To ensure that a module interface is always built using the
language mode that its source code was originally built with, require an
explicit `-language-mode` option when emitting swiftinterface files.
Resolves rdar://145168219.
Declarations that are unavailable at runtime because of an `@available`
attribute referencing a custom domain that was imported `@_spiOnly` should be
hidden from public swiftinterface files in `-library-level=api` modules. For
remaining declarations that do get printed in the public swiftinterface, skip
printing any `@available` attribute that refers to the domains from those
`@_spiOnly` dependencies. This allows API developers to control declaration
visibility using availability defined by another module.
Resolves rdar://156512028.
When a function parameter has attached property wrappers (SE-0293) those
property wrappers are either considered "implementation" or "API" level.
Property wrappers that are implementation-level don't affect how the function
is called and therefore shouldn't be included in swiftinterfaces unless the
function's body is also printed.
Resolves rdar://156711817.
