Swift 5.5 didn't support back deployment of concurrency features, so a
Swift 5.5 compiler processing the _Concurrency .swiftinterface will
produce errors for each `async` function and actor with pre-macOS
12/iOS 15 availability. Emit `-disable-availability-checking` into the
generated `.swiftinterface` files to allow Swift 5.5 to continue to
build them.
Finishes rdar://82602353.
We should hold off actually building the binary module file until it is imported.
`canImport` queries can happen, for example, during dependency scanning, when we do not wish to have the scanner tool execute any module builds.
Resolves rdar://82603098
The Swift driver is passing the optimization record file path via the supplementals output, instead of the flag, on certain circumstances.
Enhance the frontend to check supplemental outputs otherwise the record file will not get emitted when using the new swift driver.
Remove the option that explicitly enables concurrency back-deployment,
and instead always enable its support in the compiler. Remove the use
of the extraneous CMake option as well.
Add a frontend-only flag `-enable-experimental-back-deploy-concurrency`
to be used to stage in the back deployment of concurrency. At present,
all it does is lower the availability minimums for use of concurrency
features.
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.
In a back deployment scenario, this will provide a place where one could provide
function implementations that are not available in the relevant stdlib.
This is just setting up for future work and isn't doing anything interesting
beyond wiring it up/making sure that it is wired up correctly with tests.
This hidden frontend option lets us be more lax
when type-checking in the presence of editor
placeholders by treating them as holes during
constraint solving.
LLVM will eventually switch over to using global-isel on arm64 archs.
Setting this option (SWIFT_ENABLE_GLOBAL_ISEL_ARM64) can be used to experiment
with that in Swift before the switch happens.
Rework Sendable checking to be completely based on "missing"
conformances, so that we can individually diagnose missing Sendable
conformances based on both the module in which the conformance check
happened as well as where the type was declared. The basic rules here
are to only diagnose if either the module where the non-Sendable type
was declared or the module where it was checked was compiled with a
mode that consistently diagnoses `Sendable`, either by virtue of
being Swift 6 or because `-warn-concurrency` was provided on the
command line. And have that diagnostic be an error in Swift 6 or
warning in Swift 5.x.
There is much tuning to be done here.
* Rename --enable-experimental-opaque-return-types and gate structural opaque types with a flag
* Separate out structural opaque type result builder tests
