Complex equality is encoded in the low bit of the witness table pointer. We need to mask off the low bits when bitcasting to an `any SerialExecutor`.
rdar://164005854
This code is public on main, but not on 6.2, so if one compiles a binary for 6.2
on main and then attempts to use a stdlib from a 6.2 aligned macOS, one gets an
ABI error since the type isn't there. Just mark these types as being available
in 6.3 so that way this is future proofed and allows for main binaries to run
against a 6.2 aligned macOS stdlib.
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`.
Previously, we skipped checking the return type of a function for safety
as we expected to warn at the use of the returned value:
let x = returnsUnsafe()
usesUnsafe(x) // warn here
Unfortunately, this resulted in missing some unsafe constructs that can
introduce memory safety issues when the use of the return value had a
different shape resulting in false negatives for cases like:
return returnsUnsafe()
or
usesUnsafe(returnsUnsafe())
This PR changes the analysis to always take return types of function
calls into account.
rdar://157237301
a550080 added a call to the new initializer, but that call
came from a function annotated with `StdlibDeploymentTarget 6.2`,
rather than `SwiftStdlib 6.2`, while the initializer was set to
`SwiftStdlib 6.2`. This will fail in some build configurations
(specifically where the target being built for is older than that
implied by `SwiftStdlib 6.2`).
rdar://157217460
The test was crashing due to `swift_unreachable("custom executors not supported in embedded Swift")` line in `swift_task_enqueueImpl`, as the corresponding non-embedded codepath was relying on an unspecialized generic function `_swift_task_enqueueOnExecutor` defined in `Executor.swift`. Unspecialized generics are unavailable in Embedded Swift, and such `@silgen_name` function can't be specialized when used from concurrency runtime code written in C/C++. We can redefine this function for Embedded Swift as using a class-bound existential instead, and re-enable this codepath with a slightly different call that avoids the use of unavailable `swift_getObjectType` function from the non-embedded runtime.
`ExecutorImpl.cpp` should be moved from `SWIFT_RUNTIME_CONCURRENCY_NONEMBEDDED_C_SOURCES` to `SWIFT_RUNTIME_CONCURRENCY_C_SOURCES`. This way we can also include `ExecutorImpl.swift` and use `PlatformExecutorCooperative.swift` in embedded concurrency for WASI.
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
If you use SwiftStdlibCurrentOS availability, you will be able to
use new types and functions from within the implementation. This
works by, when appropriate, building with the CurrentOS availability
set to the current deployment target.
rdar://150944675
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
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
I had originally thought that we'd get away without this because the
executor construction generally happens in the async `main` function,
but of course if a program doesn't already use Swift Concurrency,
and someone uses it from a plug-in or library it loads, there's a
risk that we might have a race condition.
rdar://149346132
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
EventableExecutor is being removed, for now, but hopefully will
return in some form in the future.
The `asSchedulable` implementation needs to change for reasons of
ABI stability.
rdar://141348916
Remove `supportsScheduling` in favour of a type-based approach.
Update the storage for `ClockTraits` to `UInt32`.
Adjust ordering of executors for `currentExecutor`.
rdar://141348916
Rename `DispatchTaskExecutor` to `DispatchGlobalTaskExecutor` as we
may want to use the former for an executor that runs things on an
arbitrary Dispatch queue.
Rename `DispatchExecutor` to `DispatchExecutorProtocol`; again, we
might want the name for something else.
Add `@Sendable` attribute to `registerEvent`.
Fix missing `extern "C" SWIFT_CC(swift)` on `_swift_exit` (merge
error).
Remove stray whitespace from `CMakeLists.txt`
rdar://141348916
Added an `-executor-factory` argument to the compiler to let you safely
specify the executors you wish to use (by naming a type that returns
them).
Also added some tests of the new functionality.
rdar://141348916
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
