It is no longer necessary to avoid using the `consume` keyword in inlinable
function bodies in the standard library in order to support older compilers.
Partially reverts https://github.com/apple/swift/pull/65599.
Resolves rdar://109165937.
All compilers that must be able to compile the standard library's textual
interface accept the following:
- back deployed functions declared without `@available`
- `@inlinable` back deployed functions
- `defer` blocks in back deployed functions
We can therefore revert the workarounds added in
https://github.com/apple/swift/pull/62946/ and
https://github.com/apple/swift/pull/62928/.
Resolves rdar://104085810
Revert a few unnecessary changes have been made to the _Concurrency module
recently that make its swiftinterface un-parseable by older compilers that we
need to support.
- The `consume` keyword is not understood by older compilers, so including it
in inlinable code is a problem. It has no actual effect on lifetimes where it
was used, so just omit it.
- Don't build the _Concurrency module with -enable-experimental-feature
MoveOnly. The MoveOnly feature is now enabled by default in recent compilers,
so the flag is superfluous when building the dylib. When emitting the
interface, having the feature enabled explicitly exposes code guarded by
`$MoveOnly` to older compilers that do not accept all of the code.
Resolves rdar://108793606
Because `_taskLocalValuePush` and `_taskLocalValuePop` can result in calls
to `swift_task_alloc` and `swift_task_dealloc` respectively, and because
the compiler hasn't been taught about that (e.g.
`SILInstruction::isAllocatingStack`,
`SILInstruction::isDeallocatingStack`, etc), calling them (push and pop)
from a function which makes use the stack for dynamically sized
allocations can result in violations of stack discipline of the form
```
swift_task_alloc // allocates %ptr_1
copy_value_witness // copies into %ptr_1
swift_task_localValuePush // calls swift_task_alloc and allocates %ptr_2
swift_task_dealloc // deallocates %ptr_1
swift_task_localValuePop // calls swift_task_dealloc and deallocates %ptr_2
```
Avoid the problem by not allocating dynamically sized stack space in the
function which calls `_taskLocalValuePush` and `_taskLocalValuePop`.
Split the calls to those functions into `withValueImpl` function which
takes its argument `__owned`. Call that function from `withValue`,
ensuring that the necessary copy (to account for the fact that withValue
takes its argument `__guaranteed` but `_taskLocalValuePush` takes its
`__owned`) and associated stack traffic occur in `withValue`.
Still, allow `withValueImpl` to be inlined. The stack nesting will be
preserved across it.
rdar://107275872
The threading library changed in the BackDeployConcurrency library
resulting in the `SWIFT_TASK_DEBUG_LOG` macro not compiling. Fixing
that. Also adding the logging pieces to the Compatibility 56 library.
Older versions of the 5.8 compiler have a bug when generating SIL for functions with `@_backDeploy` containing defer blocks (https://github.com/apple/swift/pull/62444) and for now we need the standard library interface to be compatible with those older compilers.
Resolves rdar://104045168
We were detaching the child by just modifying the list, but the cancellation path was assuming that that would not be done without holding the task status lock.
This patch just fixes the current runtime; the back-deployment side is complicated.
Fixes rdar://88398824
This replaces a number of `#include`-s like this:
```
#include "../../../stdlib/public/SwiftShims/Visibility.h"
```
with this:
```
#include "swift/shims/Visibility.h"
```
This is needed to allow SwiftCompilerSources to use C++ headers which include SwiftShims headers. Currently trying to do that results in errors:
```
swift/swift/include/swift/Demangling/../../../stdlib/public/SwiftShims/module.modulemap:1:8: error: redefinition of module 'SwiftShims'
module SwiftShims {
^
Builds.noindex/swift/swift/bootstrapping0/lib/swift/shims/module.modulemap:1:8: note: previously defined here
module SwiftShims {
^
```
This happens because the headers in both the source dir and the build dir refer to SwiftShims headers by relative path, and both the source root and the build root contain SwiftShims headers (which are equivalent, but since they are located in different dirs, Clang treats them as different modules).
The continuation types were conditionally `Sendable` based on whether
the result type of the continuation was `Sendable`. However,
conceptually, the return value is never leaving the current task, so
it is never actually crossing concurrency boundaries. Therefore, we
can make the continuation types unconditionally `Sendable`.
Fixes rdar://98462858.
The new intrinsic, exposed via static functions on Task<T, Never> and
Task<T, Error> (rethrowing), begins an asynchronous context within a
synchronous caller's context. This is only available for use under the
task-to-thread concurrency model, and even then only under SPI.
A copy of the older Concurrency sources was just added to BackDeployConcurrency,
replacing the `add_subdirectory(../Concurrency)` trick it was using previously.
These need to be adjusted to work with the threading library. Fortunately, the
necessary adjustments are the same as those required for the existing
Concurrency library, give or take.
rdar://90776105
SWIFT_STDLIB_SINGLE_THREADED_RUNTIME is too much of a blunt instrument here.
It covers both the Concurrency runtime and the rest of the runtime, but we'd
like to be able to have e.g. a single-threaded Concurrency runtime while
the rest of the runtime is still thread safe (for instance).
So: rename it to SWIFT_STDLIB_SINGLE_THREADED_CONCURRENCY and make it just
control the Concurrency runtime, then add a SWIFT_STDLIB_THREADING_PACKAGE
setting at the CMake/build-script level, which defines
SWIFT_STDLIB_THREADING_xxx where xxx depends on the chosen threading package.
This is especially useful on systems where there may be a choice of threading
package that you could use.
rdar://90776105
When initializing an actor, job, or task, use _swift_instantiateInertHeapObject to have the OS's libswiftCore set up the object's refcounts field, to ensure we get a valid initial state.
There is no equivalent for immortal objects, but by a stroke of luck the new representation for immortal refcounts happens to set the immortal bit in the old representation.
rdar://93087343
