Memory allocation in Swift should always go through the common Swift
entrypoints rather than have calls directly into the C standard
library. This goes through the platform abstraction layer in Embedded
Swift, for platforms that may not have a C standard library.
Fatal errors in the concurrency runtime used a mix of
swift_Concurrency_fatalError[v] and manual calls to abort(). Drop the
dependency on abort() by routing all true fatal errors through
swift_Concurrency_fatalErrorv and eventually to a new
`_swift_fatalError` C entrypoint defined in the Embedded Swift
runtime, which (optionally) prints and then (always) traps.
This function isn't used in the Embedded Concurrency library, and
refers to another logging function that isn't provided in the Embedded
Swift runtime.
We were crashing when using this hook function because the hook points
at a Swift function, which expects `self` to be set, but we weren't
telling the C compiler and so when we called through the function pointer
from C++ code, the relevant register wasn't set and we'd crash.
Fixes#85134
rdar://163401438
Now that we have untyped throws support in Embedded Swift, remove the
special cases that trapped when a task (or anything built on it)
throws. Introduce some tests that ensure that we can throw errors
through a Task or "async let" and catch the error.
Fixes rdar://175590869.
This is a follow up from the "async" `deinit` work, which will allow us
to guarantee cleanup code to run in deinitializers, even if they need to
call asynchronous code, and even if they may be run in a task that was
cancelled: by "shielding" it from cancellation.
This is incomplete, the child handling needs some more love.
SE proposal: https://github.com/swiftlang/swift-evolution/pull/3037/
functions.
These were introduced in an early draft implementation of async let, but
never used by a released compiler. They are not used as symbols by any
app binaries. There's no reason to keep carrying them.
While I'm at it, dramatically improve the documentation of the remaining
async let API functions.
Most of linkers pull object files from static archives only if any
symbol from that object file is referenced, even if the object contains
a ctor code. `Setup.cpp` didn't have any symbols referenced from
other code, so it was not linked in when the concurrency runtime was
linked in statically. This commit moves the ctor code to `Task.cpp`
to ensure that it is always linked in.
We missed to sign the handler. Along the way the signature of it
changed, so adjust for that.
How to get the number:
```
func PROPER(bar: (TaskPriority, TaskPriority) -> Void) {
let p = TaskPriority.default
bar(p, p)
}
```
```
-> % swiftc -target arm64e-apple-macos13 example.swift -S -o - | swift demangle | grep -a3 autda
stur x8, [x29, #-64]
mov x17, x8
movk x17, #11839, lsl #48 <<<<<<<<<
autda x16, x17
ldr x8, [x16, #64]
lsr x8, x8, #0
add x8, x8, #15
```
Resolves rdar://150378890
We were failing to switch executors to Dispatch queues, where those
were being used as executors, which caused a variety of unusual
symptoms.
rdar://150310927
Function types aren't always trivially copyable, e.g. with address-discriminated signed pointers on ARM64e. Introduce a function_cast helper and use that instead.
Iterating child tasks depends on knowing the size of AsyncTask, and changing the size of the task broke it. Instead of relying on mirroring the full structure in our out-of-process definitions, add a debug variable to libswift_Concurrency that contains the size of AsyncTask.
While we're there, add some more validation to child task enumeration. Check each child task's metadata pointer to make sure that it actually points to the AsyncTask metadata, and have the inner loop also increment and check ChildTaskLoopCount to stop runaway iteration in that loop.
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
Tweaked diagnostic to use a string instead of a type. Renamed the
feature in `FeatureAvailability.def` (and added the `TaskExecutor`
feature to 6.2). Also fixed the `swift_getActiveExecutor()`
function to return the main executor only when on the main thread.
rdar://141348916
The newer clang properly identifies UB on invalid pointer casts. This
was previously being silenced by suppressing the warnings. Adjust the
code to use `std::bit_cast` (or the shim implementation) to avoid the
UB in this code.
Reorganise the Concurrency code so that it's possible to completely
implement executors (both main and global) in Swift.
Provide API to choose the desired executors for your application.
Also make `Task.Sleep` wait using the current executor, not the global
executor, and expose APIs on `Clock` to allow for conversion between
time bases.
rdar://141348916
* [Concurrency] Initial steps for startSynchronously for Task
* [Concurrency] Rename to _startSynchronously while in development
* [Concurrency] StartSynchronously special executor to avoid switching
* startSynchronously bring back more info output
* [Concurrency] startSynchronously with more custom executor tests
* add missing ABI additions to test for x86
* [Concurrency] gyb generate _startSynchronously
* [Concurrency] %import dispatch for Linux startSynchronously test
* [Concurrency] Add TaskGroup.startTaskSynchronously funcs
* [Concurrency] DispatchSerialQueue does not exist on linux still
Previously these records were not used at all, so changing this has no
impact on existing runtimes. Note that we changedd the FunctionType
because the previous one was slightly incorrect -- the context comes
LAST in the type, not first.