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.
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.
* docs: improve withTaskCancellationHandler docs
* prefer using non-deprecated withCancHandler method
* Apply suggestions from code review
Co-authored-by: Alex Martini <amartini@apple.com>
---------
Co-authored-by: Alex Martini <amartini@apple.com>
Under the task-to-thread model, specifying a priority doesn't make
sense.
Here, variations of addTask and addTaskUnlessCancelled are introduced
which do not take a priority. Additionally, the original functions are
made unavailable.
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.
Based on feedback from the second review, we decided to go with
high/default/low/background, with aliases for the Dispatch-inspired
names. While here, make TaskPriority be backed by a UInt8 to better
describe the actual restrictions, and start removing userInteractive,
because clients shouldn't be able to specify it.
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.
