* [Concurrency] Initial steps for startSynchronously for Task
* [Concurrency] Rename to _startSynchronously while in development
* [Concurrency] StartSynchronously special executor to avoid switching
* startSynchronously bring back more info output
* [Concurrency] startSynchronously with more custom executor tests
* add missing ABI additions to test for x86
* [Concurrency] gyb generate _startSynchronously
* [Concurrency] %import dispatch for Linux startSynchronously test
* [Concurrency] Add TaskGroup.startTaskSynchronously funcs
* [Concurrency] DispatchSerialQueue does not exist on linux still
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.
* Add missing period at end of sentence
* Add missing period
Co-authored-by: LamTrinh.Dev <me@lamtrinh.dev>
---------
Co-authored-by: LamTrinh.Dev <me@lamtrinh.dev>
Extend the _unsafeInheritExecutor_ workaround to all remaining APIs in the
Concurrency library that have adopted `#isolation` default arguments to
(safely) stay in the caller's isolation domain...
... except one. Clock.measure() is currently running into problems with
the type checker workaround and needs a little more thought.
Fixes rdar://131760111.
Supported older compilers don't enable this feature by default, so it can't be
omitted from the `_Concurrency` module's flags (regression from
https://github.com/swiftlang/swift/pull/74543).
Additionally, remove `@_allowFeatureSuppression(IsolatedAny)` from all
declarations. We no longer need to support compilers that don't have the
`IsolatedAny` feature, so the suppression is superfluous and the alternative
branches didn't actually build anyways. _Additionally_, the suppressible
feature logic could not handle suppressing `IsolatedAny` simultaneously with
`SendingArgsAndResults`, resulting in a broken interface because `sending` was
used outside `#if $SendingArgsAndResults` guards.
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.
