Rather than just looking at top level in the module, start by searching
the type marked as `@main`. This means that a library that provides a
protocol or superclass that the `@main` type can conform to can specify
an executor in a reasonable manner.
We no longer attempt to convert timestamps from the passed-in `Clock`
in order to allow any clock to work with any executor. Instead,
executors that do not recognise a clock should call the `enqueue`
function on that `Clock`, which lets the `Clock` itself decide how
to proceed.
Additionally, rename `SchedulableExecutor` to `SchedulingExecutor`.
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
