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.
Not inheriting the caller's executor is a major problem for
these functions. Under SE-0338, treating them as non-isolated
means that it's illegal to pass them anytthing non-Sendable
from a different isolation context; since the function is
declared to take a non-sendable function parameter, effectively,
SE-0338 means that these functions can only be safely called
from non-isolated contexts. That's not really acceptable, but
it gets worse: since we haven't implemented the sendability
rule for that yet, we're immediately bypassing isolation safety
when using these functions with no warning.
The `withCheckedContinuation` functions are not
`@_alwaysEmitIntoClient` (an oversight in the initial release),
and so we need to use the unsafe attribute on them. When we
eventually implement a safe mechanism for this, we should make
`@_alwaysEmitIntoClient` variants of these functions which use
the new feature, and we can demote the existing functions to
`internal @availableFromInline`.
I've gone ahead and made `withChecked*Continuation` `@inlinable`.
Make the continuation type's conformances to the `Sendable` protocol
conditional on the sendability of the result yielded when the
resumption is performed. This ensures that one cannot silently escape
a continuation's result out of a task or actor, closing a safety hole
in Sendable checking.
Fixes rdar://85419546.
The concurrency runtime now deploys back to macOS 10.15, iOS 13.0, watchOS 6.0, tvOS 13.0, which corresponds to the 5.1 release of the stdlib.
Adjust macro usages accordingly.
I am going to use this to test that we propagate synchronous accesses into
asynchronous tasks access sets.
To ensure this is not ABI, I underscored/marked this as alwaysEmitIntoClient.
Introduce a fake (but non-ABI) declaration to the swiftinterface
which marks that an SDK support swift_continuation_await, and then
only call it if that declaration exists, otherwise falling back
on the old atomic sequence. Using that sequence will badly mess
up the runtime's tracking of task state, but it might still work,
and more importantly things will still build, which solves the
short-term problem. Hopefully we can remove this hack soon.
Fixes rdar://problem/80787731.
The `Task` type has oscillated somewhat from being purely a namespace,
to having instances that are used (albeit rarely), back to purely
being a namespace that isn't used for all that many names. Many of the
names that used to be on Task have already been moved out, e.g., for
creating new detached tasks, creating new task groups, adding
cancellation handlers, etc.
Collapse `Task.Handle<Success, Failure>` into `Task<Success, Failure>`.
`Task.Handle` is the type that is most frequently referenced in the
concurrency library, so giving it the short name `Task` is most
appropriate. Replace the top-level async/detach functions with a
`Task` initializer and `Task.detached`, respectively.
The `Task` type can still act as a namespace for static operations
such as, e.g., `Task.isCancelled`. Do this with an extension of the
form:
extension Task where Success == Never, Failure == Never { ... }
We've been accruing a number of compatibility shims. Move them all
into their own source file, deprecate them, and make them
always-emit-into-client so they don't have any ABI impact.
- Introduce an UnownedSerialExecutor type into the concurrency library.
- Create a SerialExecutor protocol which allows an executor type to
change how it executes jobs.
- Add an unownedExecutor requirement to the Actor protocol.
- Change the ABI for ExecutorRef so that it stores a SerialExecutor
witness table pointer in the implementation field. This effectively
makes ExecutorRef an `unowned(unsafe) SerialExecutor`, except that
default actors are represented without a witness table pointer (just
a bit-pattern).
- Synthesize the unownedExecutor method for default actors (i.e. actors
that don't provide an unownedExecutor property).
- Make synthesized unownedExecutor properties `final`, and give them
a semantics attribute specifying that they're for default actors.
- Split `Builtin.buildSerialExecutorRef` into a few more precise
builtins. We're not using the main-actor one yet, though.
Pitch thread:
https://forums.swift.org/t/support-custom-executors-in-swift-concurrency/44425
This allows programs to target older OSes while using Concurrency behind an availability check. When targeting older OSes, the symbols are weak-linked and the compiler will require the use of Concurrency features to be guarded by an availability check.
rdar://75850003
The immediate desire is to minimize the set of ABI dependencies
on the layout of an ExecutorRef. In addition to that, however,
I wanted to generally reduce the code size impact of an unsafe
continuation since it now requires accessing thread-local state,
and I wanted resumption to not have to create unnecessary type
metadata for the value type just to do the initialization.
Therefore, I've introduced a swift_continuation_init function
which handles the default initialization of a continuation
and returns a reference to the current task. I've also moved
the initialization of the normal continuation result into the
caller (out of the runtime), and I've moved the resumption-side
cmpxchg into the runtime (and prior to the task being enqueued).
The goal of doing this is to reduce the amount of boilerplate and repeated code w.r.t. Continuation. Having just added `resume()` in four places, I got the sense that there was a lot of common code that was being duplicated. I removed the Throwing variants of these types (they can be expressed as Continuation<T, E:Error> instead of ThrowingContinuation<E>) and I broke out a significant amount of common code between CheckedContinuation and UnsafeContinuation into an implementation-only protocol to avoid repeating it. D.R.Y.
This change resolves rdar://74154769.
This change implements the changes proposed in swift-evolution PR #1264.
Existing test coverage should be sufficient here since the added function
simply calls into the existing `resume(returning:)` function.
This change resolves rdar://74031110.
The `try await` ordering is both easier to read and indicates the order
of operations better, because the suspension point occurs first and
then one can observe a thrown error.
We somehow ended up with a set hidden in `Task` as well as a set at top level. SILGen currently
hooks into the top-level ones, so shed the `Task`-namespaced versions for now.
`get_async_continuation[_addr]` begins a suspend operation by accessing the continuation value that can resume
the task, which can then be used in a callback or event handler before executing `await_async_continuation` to
suspend the task.
The experimental concurrency model will require a supporting runtime
and possibly end-user-visible library constructs. Introduce a stub of
such a library, enabled by a new `build-script` option
`--enable-experimental-concurrency`, so we have a place to put this
work.
