Through various means, it is possible for a synchronous actor-isolated
function to escape to another concurrency domain and be called from
outside the actor. The problem existed previously, but has become far
easier to trigger now that `@escaping` closures and local functions
can be actor-isolated.
Introduce runtime detection of such data races, where a synchronous
actor-isolated function ends up being called from the wrong executor.
Do this by emitting an executor check in actor-isolated synchronous
functions, where we query the executor in thread-local storage and
ensure that it is what we expect. If it isn't, the runtime complains.
The runtime's complaints can be controlled with the environment
variable `SWIFT_UNEXPECTED_EXECUTOR_LOG_LEVEL`:
0 - disable checking
1 - warn when a data race is detected
2 - error and abort when a data race is detected
At an implementation level, this introduces a new concurrency runtime
entry point `_checkExpectedExecutor` that checks the given executor
(on which the function should always have been called) against the
executor on which is called (which is in thread-local storage). There
is a special carve-out here for `@MainActor` code, where we check
against the OS's notion of "main thread" as well, so that `@MainActor`
code can be called via (e.g.) the Dispatch library's
`DispatchQueue.main.async`.
The new SIL instruction `extract_executor` performs the lowering of an
actor down to its executor, which is implicit in the `hop_to_executor`
instruction. Extend the LowerHopToExecutor pass to perform said
lowering.
* [stdlib] Set.intersection iterate over smaller set
When intersecting two sets, it is beneficial to iterate over the smaller sized set of the two, and check membership on the other. This speeds up runtime dramatically for cases where the current set is significantly larger than the set you are intersecting against.
* Review comments - variable names, implicit swap
`TaskGroup::offer(completedTask)`:
* Called from `AsyncTask::completeFuture()` which already takes care of
`release(completedTask)`. No additional edge is required if no task
is waiting and completed task is stored so it can be retrieved by
`group.poll()`.
* If group has waiting task, it will be dequeued and scheduled, add
`acquire(waitingTask)`.
`TaskGroupImpl::poll(waitingTask)`:
* If no pending tasks, do nothing.
* If returning finished task, `acquire(finishedTask)`.
* If enqueuing waiting task, `release(waitingTask)`.
Note: `release()` should go before, and `acquire()` after the annotated
synchronization operation.
Radar-Id: rdar://75910632
The callbacks made in ImageInspectionMachO.cpp are called in a dangerous context, with the dyld and ObjC runtime locks held. C++ allows programs to overload the global operator new/delete, and there's no guarantee that those overloads behave. Ideally, we'd avoid them entirely, but that's a bigger job. For now, avoid the worst trouble by avoiding STL and new/delete in these callbacks. That use came from ConcurrentReadableArray's free list, so we switch that from a std::vector to a linked list.
rdar://75036800
- stop storing the parent task in the TaskGroup at the .swift level
- make sure that swift_taskGroup_isCancelled is implied by the parent
task being cancelled
- make the TaskGroup structs frozen
- make the withTaskGroup functions inlinable
- remove swift_taskGroup_create
- teach IRGen to allocate memory for the task group
- don't deallocate the task group in swift_taskGroup_destroy
To achieve the allocation change, introduce paired create/destroy builtins.
Furthermore, remove the _swiftRetain and _swiftRelease functions and
several calls to them. Replace them with uses of the appropriate builtins.
I should probably change the builtins to return retained, since they're
working with a managed type, but I'll do that in a separate commit.
* Implement a YieldingContinuation type suitable for emitting values more than once via a yielding family of functions and awaiting production via next
* Add availability for YieldingContinuation and tests
* remove UnsafeConcurrentValue
* use UnsafeSendable for now
* Ensure the testing contexts are actually async
* Change the usages of Task.runDetached to Task.detach
* Change the usages of Task.detach to detach
* Transition to a external storage class outside of the generic, move to acqrel atomics, and change the error type to be enforced to Error existentials for next.
* Apply suggestions from code review
Co-authored-by: Nate Cook <natecook@apple.com>
* Remove inlines to allow for resilient changes
* Add unreachable cases in testing
Co-authored-by: Nate Cook <natecook@apple.com>
For ordinary memory-management reasons, this should only ever
happen when there will be no more uses of the actor outside of the
actor runtime. The actor runtime, meanwhile, doesn't care about
anything except the default-actor control state of the actor. So
we can just allow the rest of the actor to be destructed when it
isn't needed anymore, then destroy the actor state and deallocate
the object when we get around to switching off the executor.
This does assume that the task doesn't do anything which semantically
detects the executor it's on before switching off it, since doing so
might read a bogus executor. However, we should only get an executor
in a zombie state like this when a hop has been removed or reordered,
and detection events should count as inhibiting that and forcing the
true executor to be switched to (and thus detected).
(But maybe lifetime optimization can make this happen? Maybe we
need semantic detection to filter out zombie executors.)
Previously, if this happened, we simply left the actor in a running
state, causing any further jobs submitted to it to never be executed.
I can only speculate why this wasn't showing up in testing.
Also, change swift_job_run so that it prevents switching if the executor
passed in is not generic. This is an entrypoint for arbitrary executors
and generally should not allow unexpected switching (if someday custom
executors participate in that scheme). This infrastructure will also
be useful for implementing the `async let` semantics of running
synchronously until the task reaches a suspension point.
Finally, improve the #if'ed logging code throughout the task/actor runtime.
Adjust the condition and message to skip the primary variant alias in a
way that's more clear and more directly matches the explanation in the
comments.
Co-authored-by: Eric Miotto <emiotto@apple.com>
Repurpose mangling operator `Y` as an umbrella operator that covers new attributes on function types. Free up operators `J`, `j`, and `k`.
```
async ::= 'Ya' // 'async' annotation on function types
sendable ::= 'Yb' // @Sendable on function types
throws ::= 'K' // 'throws' annotation on function types
differentiable ::= 'Yjf' // @differentiable(_forward) on function type
differentiable ::= 'Yjr' // @differentiable(reverse) on function type
differentiable ::= 'Yjd' // @differentiable on function type
differentiable ::= 'Yjl' // @differentiable(_linear) on function type
```
Resolves rdar://76299796.
`@noDerivative` was not mangled in function types, and was resolved incorrectly when there's an ownership specifier. It is fixed by this patch with the following changes:
* Add `NoDerivative` demangle node represented by a `k` operator.
```
list-type ::= type identifier? 'k'? 'z'? 'h'? 'n'? 'd'? // type with optional label, '@noDerivative', inout convention, shared convention, owned convention, and variadic specifier
```
* Fix `NoDerivative`'s overflown offset in `ParameterTypeFlags` (`7` -> `6`).
* In type decoder and type resolver where attributed type nodes are processed, add support for nested attributed nodes, e.g. `inout @noDerivative T`.
* Add `TypeResolverContext::InoutFunctionInput` so that when we resolve an `inout @noDerivative T` parameter, the `@noDerivative T` checking logic won't get a `TypeResolverContext::None` set by the caller.
Resolves rdar://75916833.
The CMake uses the concept of a "primary variant" which isn't
necessarily aligned with either the host or target. In some cases, like
cross-compiling an iOS compiler toolchain for macosx-arm64, the expected
"primary variant" target will be missing and so CMake will fail. We can
skip adding the alias since build-script will call the more specific
target anyway.
* Move TSan function lookup out of the common path
Move TSan function lookup via `dlsym()` out of the common path. The
TSan runtime will now call `__tsan_on_initialize()` which we can use to
initialize the TSan functions in the Swift runtime.
This avoids paying the cost of `dlsym()` in the common, non-TSan case.
Depends on: https://reviews.llvm.org/D98810
rdar://75493372
* Remove Windows code
Thread Sanitizer is not supported on Windows.
Co-authored-by: Julian Lettner <julian.lettner@apple.com>
Previously, AsyncFunctionPointer constants were signed as code. That
was incorrect considering that these constants are in fact data. Here,
that is fixed.
rdar://76118522
