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
NFC *except* that I noticed a bug by inspection where we suppress
`@escaping` when print enum element types. Since this affects
recursive positions, we end up suppressing `@escaping` in places
we shouldn't. This is unlikely to affect much real code, but should
still obviously be fixed.
The new design is a little sketchy in that we're using `const` to
prevent direct use (and allow initialization of `const &` parameters)
but still relying on modification of the actual object. Essentially,
we are treating the `const`-ness of the reference as a promise to leave
the original value in the object after computation rather than a
guarantee of not modifying the object. This is okay --- a temporary
bound to a `const` reference is still a non-`const` object formally
and can be modified without invoking UB --- but makes me a little
uncomfortable.
