Adds frontend option -enable-stack-protector to enable emission of a
stack protector.
Disabled by default.
When enabled enables LLVM's strong stack protection mode.
rdar://93677524
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
Put pointers to class_ro_t referenced from generic class patterns in a section __swift_rodatas such that they are discoverable by the linker.
The linker can then make the method lists contained in the class_ro_t relative like it can for objective c class metadata from non-generic swift classes.
rdar://66634459
This flag is required in the driver to eg. choose `clang` vs `clang++`
for the linker. Move it back to a driver option and hide both it and the
stdlib flag from help.
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
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`
`.swiftinterface` files contain a list of compiler flags that were used to build the module. For example, the list includes `-enable-objc-interop`. It should also include `-enable-experimental-cxx-interop`, since it affects the way the module should be imported.
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
We add a new flag to disable the implicit import of `_StringProcessing`, similar to `-disable-implicit-concurrency-module-import`. We need this to build `_RegexParser` when `-enable-experimental-string-processing` is enabled by default, because `_StringProcessing` currently imports `_RegexParser` publicly (non-implementation-only).
Complete support is behind a flag, because it can result in a non-convergent
rewrite system if the opaque result type has a recursive conformance of its
own (eg, `some View` for SwiftUI's View protocol).
Without the flag, it's good enough for simple examples; you just can't have
a requirement that mentions a nested type of a type parameter equated to
the concrete type.
Fixes rdar://problem/88135291, https://bugs.swift.org/browse/SR-15983.
