With the introduction of `next(isolation:)` into the task group types,
we removed the public APIs for the no-argument `next()` versions,
leaving them only as `@usableFromInline internal` entrypoints for the
ABI. Because the `next(isolation:)` versions have a default argument,
this was sufficient for providing source compatibility for calls, but
not for protocol conformances.
Bring these APIs back publicly. Fixes rdar://127499568.
To preserve compatibility with older compilers that do not allow `IsolatedAny`
to be enabled in production compilers, use an alias experimental feature when
building the stdlib (`IsolatedAny2`).
Also, add `@_allowFeatureSuppression(IsolatedAny)` in a couple spots it was
forgotten.
Partially resolves rdar://125138945
Use an optional isolated parameter to this new `next(_:)` overload to
keep it on the same actor as the caller, and pass `#isolation` when
desugaring the async for..in loop. This keeps async iteration loops on
the same actor, allowing non-Sendable values to be used with many
async sequences.
We say in a comment here that we print the error and cancel, but we don't actually have the print below. This PR adds that missing print in the docs snippet.
* [Concurrency] Fix too optimistic bail-out-when-empty, discarding group
may need to emit an error out of such waitAll attempt, if a previous
error was already stored.
* [Concurrency] DiscardingTG error thrown from body always wins
* Offering body error must be done while holding lock
* Must not modify waitingTask context outside lock
* wip on trying to fix by changing the offer
* fix bug in resuming tasks in offer/resume task in discarding group
* Fix#63147 waitForAll impl in ThrowingTaskGroup, used to not wait enough
rdar://104507347
* done
* debug
* explicitly declare virtual destructors
* detach child task after filling result; dont mutate context outside of lock
* Add pending count overflow protection to TaskGroup
* unlock async_taskgroup_void_neverConsumingTasks again rdar://104332560
* missing include on windows for error reporting
* fix ARM_ARCH_7K workaround snippet
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.
handler of parent task that created the group
Change comment in TaskGroup.swift to enforce that only parent task can
call cancelAll on the group
Add tests to verify mutating of task group in child tasks will fail
Radar-Id: rdar://problem/86346865
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.
Top-level functions still encode inferred requirements in the mangled name.
In this case, `Sendable` has no ABI impact beyond the effect on the mangled
name, so fix the mangled names to maintain ABI.
Fixes rdar://83617067.
We erroneously marked this API as `throws`, even though it returns its
error via a `Result` instead. Remove the `throws` in a strange-looking
manner so that we maintain the existing ABI.
Fixes rdar://81585954.
Do this as a staged change to the ABI, introducing an underscored
`@usableFromInline` implementation to the ABI that we can rely on
later, and an `@_alwaysEmitIntoClient` version we can inline now.
The `swift_task_create` entry point is our general runtime ABI for
launching tasks. Make the various Swift APIs sitting on top of it
always-emit-into-client to take them out of the ABI. This reduces the
number of ABI entry points and allows us to make more ABI-compatible
changes to the Swift side.
Rather than using group task options constructed from the Swift parts
of the _Concurrency library and passed through `createAsyncTask`'s
options, introduce a separate builtin that always takes a group. Move
the responsibility for creating the options structure into IRGen, so
we don't need to expose the TaskGroupTaskOptionRecord type in Swift.
