I am separating the concern of weakly linking symbols that are introduced at the deployment target from the concern of type checking this new type of potential unavailability.
Resolves rdar://97925900
This was already enabled as part of `-enable-implicit-dynamic` but this
new flag allows turning on opaque type erasure all by itself whether or
not `dynamic` is added explicitly.
rdar://97375478
Introduce the `-enable-upcoming-feature X` command-line argument to
allow one to opt into features that will be enabled in an upcoming language
mode. Stage in several features this way (`ConciseMagicFile`,
`ForwardTrailingClosures`, `BareSlashRegexLiterals`).
Defined SWIFT_STDLIB_TASK_TO_THREAD_MODEL_CONCURRENCY to describe
whether the standard library will use the task-to-thread model for
concurrency. It is true only for freestanding non-Darwin stdlibs.
When it is true, SWIFT_CONCURRENCY_TASK_TO_THREAD_MODEL is defined
during stdlib compilation of both Swift and C++ sources.
Added an option to LangOptions to specify which concurrency model is
used, either standard or task-to-thread. When
SWIFT_STDLIB_TASK_TO_THREAD_MODEL_CONCURRENCY is true, the model is
specified to be task-to-thread.
When developing a module for an OS or SDK, one may use declarations from other modules that were recently introduced in the in-development OS. Those declarations will be annotated as available at the deployment target of the client module and yet the symbols for that declaration are not available in all development builds of that OS. If the module strongly links those symbols, it will crash on older development builds of the OS. The `-enable-experimental-ad-hoc-availability` flag is designed to give developers the option of weakly linking all symbols in other modules that were introduced at the deployment target.
This change introduces the basic change in linking behavior but does not address typechecking. Use of the declarations that are made unavailable in this mode will need to be diagnosed and developers will need a way to detect the unavailability at runtime before use.
Resolves rdar://96011550
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.
