Instead, use the `%target-swift-5.1-abi-triple` substitution to compile the tests
for deployment to the minimum OS versions required for use of _Concurrency APIs.
* Enable running tests from test/Concurrency/ directory in freestanding/minimal presets
* Mark failing Concurrency tests as XFAIL/SKIP on freestanding/minimal
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.
Rather than blanket-disabling concurrency tests when we aren't using a
just-built concurrency library, enable them whenever we have a
suitable concurrency runtime, either just-built, in the OS, or via the
back-deployment libraries.
If we didn't do this (and we didn't), the tasks get released as we
perform the next() impl, and move the value from the ready task to the
waiting task. Then, the ready task gets destroyed.
But as the task group exists, it performs a cancelAll() and that
iterates over all records. Those records were not removed previously
(!!!) which meant we were pointing at now deallocated tasks.
Previously this worked because we didn't deallocate the tasks, so they
leaked, but we didn't crash. With the memory leak fixed, this began to
crash since we'd attempt to cancel already destroyed tasks.
Solution:
- Remove task records whenever they complete a waiting task.
- This can ONLY be done by the "group owning task" itself, becuause
the contract of ONLY this task being allowed to modify records. o
It MUST NOT be done by the completing tasks as they complete, as it
would race with the owning task modifying this linked list of child
tasks in the group record.
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.
This allows programs to target older OSes while using Concurrency behind an availability check. When targeting older OSes, the symbols are weak-linked and the compiler will require the use of Concurrency features to be guarded by an availability check.
rdar://75850003
- introduce UnsafeCurrentTask
- implement Hashable, Equatable on tasks
- assume we'll have a way to get a task from sync context
- Task.Handle now has a Failure type as well
- Task.Handle.getResult
The pr #35755 changed these tests from `REQUIRES: OS=macosx` to using
`XFAIL: linux`, which suggests other platforms supporting concurrency
must affirmatively mark these failing tests XFAIL as well.
This is distinct from #35759, since ideally that pr will be cherrypicked
over to the 5.4 branch and including these changes there would cause a
prospective cherrypick to diverge.
The `try await` ordering is both easier to read and indicates the order
of operations better, because the suspension point occurs first and
then one can observe a thrown error.
