**Description**: This adds "task name" parameter to all task creating
functions.
This is done in a few ways, e.g. we can backdeploy this to 5.1 in APIs
which do not accept the `TaskExecutor` but it they do we provide a
version for 6.0+ etc. This was requested in the SE acceptable of this
proposal [Acceptance post
SE-0469](https://forums.swift.org/t/accepted-with-modifications-se-0469-task-naming/79438).
This moves all these declarations to gyb since going through them one by
one has become unmaintainable otherwise.
**Scope/Impact**: All task creation APIs now gain a new task name
parameter.
**Risk:** Medium, changes existing APIs rather than adding "even more
overloads" though this risk was discussed in the team and accepted. This
has a potential to be source breaking it someone used Task.init and
friends as function.
**Testing**: CI testing, source compatibility suite testing
**Reviewed by**:
**Original PR:**
- https://github.com/swiftlang/swift/pull/81107 build changes required
for this
- https://github.com/swiftlang/swift/pull/80984
**Radar:**
---------
Co-authored-by: Kuba Mracek <mracek@apple.com>
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.
