and make `@_unsafeInheritExecutor` a suppressible feature.
Some language features are required in order to parse a
declaration correctly, but some can safely be ignored.
For the latter, we'd like the module interface to simply
contain the declaration twice, once with the feature and
once without. Some basic support for that was already
added for the SpecializeAttributeWithAvailability feature,
but it didn't interact correctly with required features
that might be checked in the same `#if` clause (it simply
introduced an `#else`), and it wasn't really set up to
allow multiple features to be handled this way. There
were also a few other places that weren't updated to
handle this, presumably because they never coincided
with a `@_specialize` attribute.
Introduce the concept of a suppressible feature, which
is anything that the ASTPrinter can modify the current
PrintOptions in order to suppress. Restructure the
printing of compatibility checks so that we can print
the body multiple times with different settings.
Print required feature checks in an outer `#if...#endif`,
then perform a separate `#if...#else...#endif` within
if we have suppressible features. If there are multiple
suppressible features, check for the most recent first,
on the assumption that it will imply the rest; then
perform subsequent checks with an `#elsif` clause.
This should be a far more solid foundation on which to
build compatibility checks in the future.
`@_unsafeInheritExecutor` needs to be suppressible
because it's been added to some rather important
existing APIs. Simply suppressing the entire decl will
effectively block old tools from using a new SDK to
build many existing projects (if they've adopted
`async`). Dropping the attribute changes the semantics
of these functions, but only if the compiler features
the SE-0338 scheduling change; this is a very narrow
window of main-branch development builds of the tools,
none of which were officially released.
When inferring Sendable for a public, frozen type, that Sendable conformance
becomes part of the contract. Therefore, don't infer this conformance
when any of instance storage is implicitly non-Sendable.
Fixes rdar://88652324.
A scoped-down version of #39307. Implement extension of bound generic types. The important bit here is in TypeCheckGeneric where we now use the underlying type of a typealias and its associated nominal type decl when we're generating substitutions for the extended type.
Put this behind a new experimental flag
-enable-experimental-bound-generic-extensions
Resolves SR-4875
Resolves rdar://17434633
Raw values of enum cases from another module are not specified in the declaration of the enum unless that enum is `@objc`. This meant that `EnumRawValuesRequest` was computing potentially incorrect raw values when the enum declaration supported it and was emitting incorrect diagnostics for other enum decls.
Resolves SR-14355 and rdar://75451691
In addition to the predefined cases, like "readnone", "readonly", etc. support providing a custom string, which will be parsed later.
Also, allow multiple effects attributes to be put onto a function.
While implicitly building .swiftinterface, the interface may import other binary modules.
These binary modules may contain serialized search paths that have been obfuscated. To help
interface building commands recover these search paths, we need to pass down the obfuscators
to the module building commands.
rdar://87840268
mangleOpaqueTypeDecl() used to enable DWARFMangling, which
ignores @_originallyDefinedIn, which would in turn break module
interfaces.
Fixes rdar://problem/86480663.
This normalizes the path so that we always have the mapping in normal
form. This fixes a bug in the cross-module import tracing, allowing us
to finally enable the test on Windows.
Ideally, module interface verification should fail the build when fatal error occurs when
type checking emitted module interfaces. However, we found it's hard to stage this phase in
because the ideal case requires all Swift adopters to have valid interfaces. This new front-end flag allows
driver to downgrade all interface verification errors to warnings as an intermediate step.
Replace the dynamic initialization of trivial globals with statically initialized globals, even in -Onone.
This is required to be able to use global variables in performance-annotated functions.
Also, it's a small performance improvement for -Onone.
The concurrency runtime now deploys back to macOS 10.15, iOS 13.0, watchOS 6.0, tvOS 13.0, which corresponds to the 5.1 release of the stdlib.
Adjust macro usages accordingly.
* Fix unnecessary one-time recompile of stdlib with -enable-ossa-flag
This includes a bit in the module format to represent if the module was
compiled with -enable-ossa-modules flag. When compiling a client module
with -enable-ossa-modules flag, all dependent modules are checked for this bit,
if not on, recompilation is triggered with -enable-ossa-modules.
* Updated tests
When type-checking a tuple construction such as
`Void()`, make sure to preserve the source info
from the argument list in the resulting
type-checked TupleExpr `()`. This is needed for
serialization to be able to grab the textual
representation.
SR-15181
rdar://83202870
This was manifesting as module interfaces printing generic parameters
as `τ_0_0` in some cases.
Note that the GSB has the same bug, so this test case will fail with
-requirement-machine=off. I don't plan on fixing the bug in the GSB
unless we need to.
Fixes rdar://problem/78977127.
When we fall back to loading an arm64e module interface during an arm64 build, we want to compile it for the arm64 target so that it is fully compatible with the module that will load it, even though the flags in the file specify the arm64e target. Rewrite the sub-invocation's TargetTriple property in this specific situation. If the two targets differ by more than just the sub-architecture, we will continue to respect the -target flag in the file.
Fixes <rdar://83056545>.
I wasn't aware that arm64e was a thing in open-source, but these two
tests are failing on Apple Silicon both on the main branch and on the
rebranch branch, so I'm disabling it for now.
The failing tests are:
- ModuleInterface/arm64e-fallback.swift
- stdlib/Reflection_objc.swift
If we are building for ARM64 but we try to import a module with only an ARM64e interface, fall back to importing said interface.
This is the reverse of a similar fallback briefly introduced last year, but removed in #31196.
DummyFramework.framework has two different properties to support two different kinds of test cases: to support ModuleInterface/build-alternative-interface-framework.swift, its macOS interfaces are broken, but to support ModuleInterface/arm64e-fallback.swift, it supports only arm64, not arm64e, on iOS. The arm64e test's behavior is about to change, which will complicate all of this. As a preliminary step, make the two tests use two different frameworks so they aren't so intertwined.
This temporarily keeps the arm64e test using the name "DummyFramework", but that will change.
When build-script is given `--back-deploy-concurrency`, also use that
to build other parts of Swift with the back-deployed versions:
* The compiler allows async and actors to be defined with the
back-deployed availability, e.g., the same as `-Xfrontend
-enable-experimental-back-deploy-concurrency`. (The latter will go
away soon)
* The standard library unit testing framework and distributed actors
library are build with the older OS versions.
* The tests use the older OS versions, with some adjustments to make
them agnostic to the back-deployment setting.
We have implemented a libSwiftDriver-based tool to generate prebuilt module cache for
entire SDKs. Anchored on the same infrastructure, we could also generate ABI baselines
for entire SDKs.
This fixes a regression from https://github.com/apple/swift/pull/36752.
Previously, a RawRepresentable enum would use the default implementation
of == from a protocol extension in the standard library. After the above
PR, we began synthesizing the == operator, just like we do for ordinary
enums.
However, when type checking an older swiftinterface file, we would
still synthesize the declaration and try to use it, even though it would
not have existed in the older dylib built with the older compiler.
Fix this by not deriving witnesses in swiftinterface files at all.
The interface should already explicitly list out all derived witnesses;
if one is not listed, it should not be derived, because it does not
exist in the dylib.
Fixes rdar://problem/80466745.
