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.
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
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://152420308
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
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.
Custom main and global executors work hasn't passed Swift Evolution yet,
so we need to avoid leaking it as API until it does.
To that end, underscore all the things.
rdar://151147606
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
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
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
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
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.
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
