This patch gets everything to the point of building the library, but it
doesn't run yet since I have missing symbols.
Unlike previous compatibility libraries and the concurrency
compatibility library, I'm organizing the headers a bit more. This is
because we're merging the two libraries into one. They share some common
header names, and while I could rename them for namespacing purposes,
it's easier to just use a directory structure for this.
The `include/Runtime` and corresponding `Runtime/` directories are for
backdeployed changes to the stdlib itself.
The `include/Concurrency` and corresponding `Concurrency/` directories
are for backdeployed changes to the concurrency runtimes.
So far, static arrays had to be put into a writable section, because the isa pointer and the (immortal) ref count field were initialized dynamically at the first use of such an array.
But with a new runtime library, which exports the symbols for the (immortal) ref count field and the isa pointer, it's possible to put the whole array into a read-only section. I.e. make it a constant global.
rdar://94185998
This reverts the revert commit df353ff3c0.
Also, I added a frontend option to disable this optimization: `-disable-readonly-static-objects`
Using the same feature set logic as experimental features, provide
feature names for "future" features, which are changes that will
become available with Swift 6. Use the feature check when determining
whether to implementation the feature instead of a language version
check, and map existing flags for these features (when available) over
to the feature set.
As an internal implementation detail, this makes it easier to reason
about when specific features are enabled (or not). If we decide to go
with piecemeal adoption support for features, it can provide an
alternative path to enabling features that feeds this mechanism.
Experimental features can only be enabled in non-production (+Asserts)
builds. They can be detected with `hasFeature` in the same manner as
"future" features.
The `-enable-experimental-feature X` flag will also look for future
features by that name, so that when an experimental feature becomes an
accepted future feature, it will still be enabled in the same manner.
Switch variadic generics over to this approach, eliminating the
specific LangOption for it.
Change the way swiftmodules built against a different SDK than their
clients are rejected. This makes them silently ignored when the module
can be rebuilt from their swiftinterface, instead of reporting a hard
error.
rdar://93257769
Swiftc port of https://github.com/apple/llvm-project/pull/4207.
This introduces a new flag, `-file-prefix-map` which can be used
instead of the existing `-debug-prefix-map` and `-coverage-prefix-map`
flags, and also remaps paths in index information currently.
So far, the swift-frontend decided by itself if CMO can be enabled. This caused problems when used with an old driver, which doesn't consider CMO.
Now, the driver decides when to use default CMO by passing this flag to swift-frontend.
```
[218/807] Building CXX object lib/Frontend/CMakeFiles/swiftFrontend.dir/CompilerInvocation.cpp.o
/home/egorzh/swift/swift/lib/Frontend/CompilerInvocation.cpp:804:28: warning: use of bitwise '|' with boolean operands [-Wbitwise-instead-of-logical]
Opts.EnableCXXInterop |= Args.hasArg(OPT_enable_experimental_cxx_interop) |
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
||
/home/egorzh/swift/swift/lib/Frontend/CompilerInvocation.cpp:804:28: note: cast one or both operands to int to silence this warning
```
The three options are now:
* `explicit`: Enforce Sendable constraints where it has been explicitly adopted and perform actor-isolation checking wherever code has adopted concurrency. (This is the default)
* `targeted`: Enforce Sendable constraints and perform actor-isolation checking wherever code has adopted concurrency, including code that has explicitly adopted Sendable.
* `complete`: Enforce Sendable constraints and actor-isolation checking throughout the entire module.
Replace `-warn-concurrency` with a more granular option
`-swift-concurrency=`, where the developer can select one of three
different "modes":
* `off` disables `Sendable` checking for most cases. (This is the Swift
5.5 and Swift 5.6 behavior.)
* `limited` enables `Sendable` checking within code that has adopted
Swift concurrency. (This is currently the default behavior.)
* `on` enables `Sendable` and other concurrency checking throughout
the module. (This is equivalent to `-warn-concurrency` now).
There is currently no distinction between `off` and `limited`. That
will come soon.
Implements the flag part of rdar://91930849.
This setups the frontend to search both an architecture suffixed and
unsuffixed path. This improves the multi-architecture setup for
Windows, enabling it use the directory form of the swift modules with
the architectures overlaying in the swift module and leaving the arch
suffixed directory for the import libraries.
This can be fully generalized as this also enables Linux to use the
multi-architecture search path for the swift modules enabling it to
eventually adopt a SDK model as well.
After the rename of the `enable-cxx-interop` option to `enable-experimental-cxx-interop` it was no longer possible to build with installed tools.
This change re-introduces the `enable-cxx-interop` option for backward compatibility
