Reorganise the Concurrency code so that it's possible to completely
implement executors (both main and global) in Swift.
Provide API to choose the desired executors for your application.
Also make `Task.Sleep` wait using the current executor, not the global
executor, and expose APIs on `Clock` to allow for conversion between
time bases.
rdar://141348916
The `_SwiftConcurrencyShims` module was imported `@_implementationOnly` which
was causing warnings to be emitted during the stdlib build. The module
currently serves no purpose; the only declaration it contains is a defunct
`_SwiftContext` struct which is not referenced by anything. The module needs to
continue to exist for source compatibility, though, since it is part of the
toolchain and imported publicly from other modules.
Annotate all of the `Unsafe*` types and `unsafe` functions in the standard
library (including concurrency, synchronization, etc.) as `@unsafe`. Add a
few tests to ensure that we detect uses of these types in clients that
have disabled unsafe code.
The move from `@_unsafeInheritExecutor` to `#isolation` for the
with*Continuation breaks code that is using `@_unsafeInheritExecutor` and
calling these APIs. This originally caused silent breakage (which manifest
as runtime crashes), and is now detected by the compiler as an error.
However, despite `@_unsafeInheritExecutor` being an unsafe,
not-intended-to-be-user-facing feature, it is indeed being used, along
with these APIs. Introduce _unsafeInheritExecutor_-prefixed versions of
the `with*Continuation` and `withTaskCancellationHandler` APIs into
the _Concurrency library that use `@_unsafeInheritExecutor`. Then,
teach the type checker to swap in these
_unsafeInheritExecutor_-prefixed versions in lieu of the originals
when they are called from an `@_unsafeInheritExecutor` function. This
allows existing code using `@_unsafeInheritExecutor` with these APIs
to continue working as it has before, albeit with a warning that
`@_unsafeInheritExecutor` has been removed.
Fixes rdar://131151376.
* [Concurrency] Fix task excutor handling of default actor isolation
The task executor API did not properly account for taking the default
actor locking into account when running code on it, we just took the job
and ran it without checking with the serial executor at all, which
resulted in potential concurrent executions inside the actor --
violating actor isolation.
Here we change the TaskExecutor enqueue API to accept the "target"
serial executor, which in practice will be either generic or a specific
default actor, and coordinate with it when we perform a
runSynchronously.
The SE proposal needs to be amended to showcase this new API, however
without this change we are introducing races so we must do this before
the API is stable.
* Remove _swift_task_enqueueOnTaskExecutor as we don't use it anymore
* no need for the new protocol requirement
* remove the enqueue(_ job: UnownedJob, isolatedTo unownedSerialExecutor: UnownedSerialExecutor)
Thankfully we dont need it after all
* Don't add swift_defaultActor_enqueue_withTaskExecutor and centralize the task executor getting to enqueue()
* move around extern definitions
These metatypes are a gateway to more incorrect
uses of these noncopyable values because we don't
yet have the corresponding runtime support yet.
The other use cases of using metatypes of
noncopyable types in generics is not high enough to
warrant people using them yet.
resolves rdar://106452518
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.
