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`
llvm/llvm-project removed the default for the `Default` argument in
522712e2d241ea33575a9c7a60ad582634f04f0d. Specify it directly in the
call to `hasFlag`.
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.
The `VersionTuple` API was changed llvm/llvm-project
219672b8dd06c4765185fa3161c98437d49b4a1b to return `VersionTuple`
from `get*Version` rather than pass in major, minor, and subminor output
parameters. Update uses to the new API.
Note that `getMacOSXVersion` is slightly different in that it returns a
boolean while taking a `VersionTuple` output parameter to match its
previous behaviour. There doesn't seem to be any use that actually
checks this value though, so we should either update the API to return
an `Optional` and actually check it *or* remove the "failure" case and
return a `VersionTuple` like all the others.
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
```
