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.
Something has changed about the CoreData module and caused the declarations in
this test interface to now be printed with `nonisolated` modifiers.
Resolves rdar://158783868.
When building a module interface for the -typecheck-module-from-interface or
-compile-module-from-interface actions, inherit and honor compiler debugging
options and emit debugging output at the end of the interface build.
It is expected to rebuild modules from swiftinterface when the C++
interop is enabled in clients. The swiftmodule produced is different.
Make sure the rebuilt module is kept under a distinct cache key to avoid
reusing previously compiled modules in an incompatible mode.
Since LayoutPrespecialization has been enabled by default in all compiler
invocations for quite some time, it doesn't make sense for it to be treated as
experimental feature. Make it a baseline feature and remove all the
checks for it from the compiler.
This is an accepted spelling for the attribute. This commit
also renames the feature flag from `ExtensibleAttribute` to
`NonexhaustiveAttribute` to match the spelling of the attribute.
This flag was not experimental for any good reason; it should always be
enabled. The flag only exists so we can introduce a new API:
UnsafeMutablePointer.mutableSpan. Supported compilers cannot handle the new API.
rdar://154247502 (Promote feature NonescapableAccessorOnTrivial to be
non-experimental)
To guard the new UnsafeMutablePointer.mutableSpan APIs.
This allows older compilers to ignore the new APIs. Otherwise, the type checker
will crash on the synthesized _read accessor for a non-Escapable type:
error: cannot infer lifetime dependence on the '_read' accessor because 'self'
is BitwiseCopyable, specify '@lifetime(borrow self)'
I don't know why the _read is synthesized in these cases, but apparently it's
always been that way.
Fixes: rdar://153773093 ([nonescapable] add a compiler feature to guard
~Escapable accessors when self is trivial)
Initially, the compiler rejected building dependencies that contained OS
versions in an invalid range. However, this happens to be quite
disruptive, so instead allow it and request that these versions be
implicitly bumped based on what `llvm::Triple::getCanonicalVersionForOS`
computes.
resolves: rdar://153205856
