Cherry-pick of #83128, #82399, and #82878, merged as ea6ca2b5db, 0c4e56174b, and e34eb3331f respectively.
**Explanation**: Currently `test/CMakeLists.txt` can only set `SWIFT_LIT_ARGS` for all tests uniformly. This means that we can't have tests for Embedded Swift with a different set of `lit.py` arguments.
Also, create new `check-swift-embedded-wasi` target from `test/CMakeLists.txt`, tweak `lit.cfg` to support WASI Clang resource dir, exclude unsupported tests based on `CPU=wasm32` instead of `OS=wasi`.
**Scope**: Limited to Embedded Swift test suite.
**Risk**: Low, due to limited scope.
**Testing**: #82878 was incubated on `main` for 2 weeks, #82399 for 3 weeks with no disruption, #83128 merged this week, but enables all these tests on CI, which are consistently passing.
**Issue**: rdar://156585717
**Reviewer**: @bnbarham
rdar://155596073 Task executors execution may not always hop as expected
I'm investigating a fix here as we speak, but disabling the specific piece of the test while we work on it.
This is the original spelling which was not accepted. We kept
it for a bit to give adopters time to switch but it's time to
remove it now.
(cherry picked from commit e108524d98)
With optimizations disabled, the InlineArray initializer uses 512kB of stack space. This can overflow the stack depending on exactly how things are set up. Reduce stack usage by manually allocating memory for the array and initializing it as a pointer to Int.
rdar://153263105
(cherry picked from commit 224dc12063)
Without this, llvm would sometimes wrongly assume there's no indirect
accesses and the optimizations can lead to a runtime crash, by
optimizing away initializing options properly.
Resolves rdar://152548190
statusCompletePendingReadyWaiting(), offer(), and poll() did a one-off compare_exchange_strong which could fail if the group was concurrently cancelled. Put these into loops so that they are retried when needed.
DiscardingTaskGroup creation passed the group result type as the task result type. waitAll() would then use the group result type when collecting task results. Since the task result type is always Void in this case, this would overflow the result buffer if the group result type was larger. This often works as it writes into the free space of the task allocator, but can crash if it happens to be at the end of a page or the group result type is particularly large.
rdar://151663730
(cherry picked from commit 5be22fa7cc)
This change aligns implementation with the current SE-0472 proposal.
(cherry picked from commit c3c1b4fca0)
(cherry picked from commit 8c05636e28)
(cherry picked from commit 0598b8c9f4)
We deallocate an instruction's packs at points where no further
control flow path uses the value. In the case of an alloc_stack,
this will be right after the dealloc_stack. Thus, if alloc_stack
allocates some packs to build type metadata for a tuple type
that contains a pack, and then proceeds to allocate a value
large enough to hold the tuple, we will free the second allocation
first, before we free the pack, as expected.
However, after stack allocating the value, alloc_stack does
some further work to emit debug info. This could result in
emission of additional metadata packs.
Split up the debug info emission into two parts; the first we do
before we perform the stack allocation, the rest we do after.
- Fixes https://github.com/swiftlang/swift/issues/67702.
- Fixes rdar://problem/141363236.
Reworking semantics of this API so disabling the flaky test, it'll have different sematntics and then the test will be adjusted
(cherry picked from commit a3762d4e19)
Previously there was still a sneaky hop which caused ordering issues.
This introduced a specific test startSynchronously_order which checks
that the task enqueues indeed are "immediate" and cleans up how we
handle this.
This also prepares for the being discussed in SE review direction of
this API that it SHOULD be ALLOWED to actually hop and NOT be
synchronous at all IF the isolation is specified on the closure and is
DIFFERENT than the callers dynamic isolation.
This effectively implements "synchronously run right now if dynamically
on the exact isolation as requested by the closure; otherwise enqueue
the task as usual".
resolves rdar://149284186
cc @drexin
(cherry picked from commit a24a28c217)
Add a test to check that attempting to `Task.sleep(until:)` passing a
time before the start of the Dispatch clocks works and doesn't wait
forever.
rdar://148899609
If the preloaded status is locked, then we need to reload it in order to distinguish between the current thread holding the lock and another thread holding the lock. Without this, if another thread holds the lock, then we won't set the is-locked bit. We'll still actually hold the lock, but other threads may perform operations locklessly if the bit is not set, which can cause a crash. By reloading status in that case, we ensure that the bit is always set correctly.
This manifested as crashes in task cancellation but could cause other task-related issues as well.
Also remove an assert of !isStatusRecordLocked() in AsyncTask::complete(). We allow other threads to access tasks and take the lock for things like cancellation, so the lock may legitimately be held at that point.
rdar://150327908
(cherry picked from commit 325b66ab20)
This changes the isIsolatingCurrentContext function to return `Bool?`
and removes all the witness table trickery we did previously to detect
if it was implemented or not. This comes at a cost of trying to invoke
it always, before `checkIsolated`, but it makes for an simpler
implementation and more checkable even by third party Swift code which
may want to ask this question.
Along with the `withSerialExecutor` function, this now enables us to
check the isolation at runtime when we have an `any Actor` e.g. from
`#isolation`.
Updates SE-0471 according to
https://forums.swift.org/t/se-0471-improved-custom-serialexecutor-isolation-checking-for-concurrency-runtime/78834/
review discussions
The IsolatedConformances feature moves to a normal, supported feature.
Remove all of the experimental-feature flags on test cases and such.
The InferIsolatedConformances feature moves to an upcoming feature for
Swift 7. This should become an adoptable feature, adding "nonisolated"
where needed.
(cherry picked from commit 3380331e7e)
Seems that during refactorings of child cancellations we somehow missed
also cancelling the group itself. It seems we did not have good test
coverage of the addTaskUnlessCancelled somehow and thus this slipped
through.
This adds a regression test for addTaskUnlessCancelled and fixes how we
handle the cancellation effect in TaskStatus.
resolves#80789
resolves rdar://149177600
We decided that using a magic typealias to set the executor factory was better
than using a compiler option. Remove the `-executor-factory` option, and replace
by looking up the `DefaultExecutorFactory` type, first in the main module, and
then if that fails in Concurrency.
rdar://149058236
These tests can fail when testing on an older OS version than the one
that will ship with Swift 6.2. Fix by disabling availability checking.
rdar://148986812
This avoids the potential to race with the triggering coming from
task_cancel, because we first set the cancelled flag, and only THEN
take the lock and iterate over the inserted records. Because of this we
could: T1 flip the cancelled bit; T2 observes that, and triggers
"immediately" during installing the handler record. T1 then proceeds to
lock records and trigger it again, causing a double trigger of the
cancellation handler.
resolves https://github.com/swiftlang/swift/issues/80161
resolves rdar://147493150
Certain dynamic casts cannot work safely with isolated conformances,
regardless of what executor the code runs on. For such cases, reject
all attempts to conform to the type.
`CooperativeExecutor` should fall back to heap allocations if the task
allocator isn't available when it's enqueuing delayed jobs.
Also, remove the reference to `DispatchGlobalExecutor` from the
custom executor test.
rdar://141348916
