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.
We should build a 64-bit value from the two 32-bit Id fields, but we were shifting one field by the other. Coincidentally, this managed to produce the correct value until the ID goes beyond 2^32, but after that it's weird and wrong.
Replace NextLinkType with Item::Kind with more clear definition.
Use llvm::PointerIntPair<>.
Use hierarchy of classes instead of optional fields inside Item.
Combined Storage::copyToOnlyOnlyFromCurrentGroup() into Storage::initializeLinkParent().
Also create parent task marker when copying items created inside withTaskGroup().
Removed Storage::peekHeadLinkType().
In embedded mode, we mustn't have references to the C++ library, because
some embedded platforms don't include the C++ library.
Additionally, it's good to avoid use of global operator new and operator
delete, because they can be globally overridden and this has bitten us
in the past.
rdar://137286187
We have been only including a subset of files and functionality on Embedded Concurrency, let's instead include all the
source files, and have a fine grained opt out on things that don't yet work. Namely, this is still avoiding clocks, task
sleeping and custom executors.
Add a test for AsyncStream and continuations on Embedded Concurrency.
The way that we include COMPATIBILITY_OVERRIDE_INCLUDE_PATH freaks out the
syntax highlighting of editors like emacs. It causes the whole file to be
highlighted like it is part of the include string.
To work around this, this patch creates a separate file called
CompatibilityOverrideIncludePath.h that just includes
COMPATIBILITY_OVERRIDE_INCLUDE_PATH. So its syntax highlighting is borked, but
at least in the actual files that contain real code, the syntax highlighting is
restored.
