Add SWIFT_DEBUG_ENABLE_TASK_SLAB_ALLOCATOR, which is on by default. When turned off, async stack allocations call through to malloc/free. This allows memory debugging tools to be used on async stack allocations.
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
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.
Item::destroy will call free when there's no task, so the allocation needs to match, lest we free something that wasn't malloced and crash.
rdar://162589711
To achieve this, add a new cache variable
`SWIFT_EMBEDDED_STDLIB_SDKS_FOR_TARGET_TRIPLES` to be set like in the
following examples.
```
-DSWIFT_EMBEDDED_STDLIB_SDKS_FOR_TARGET_TRIPLES=aarch64-vendor-os@/usr/local/aarch64-vendor-os-sdk;aaarch-vendor-anotheros@/opt/aarch64-vendor-anotheros-sdk
```
We chose to use another setting instead of e.g. folding this into
`SWIFT_EMBEDDED_STDLIB_EXTRA_TARGET_TRIPLES` so it is clear this is opt
in and it does not regress existing configurations that set the SDK
directly (like it's the case for the WASM stdlib).
Addresses rdar://162368529
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 need the `init?(JobPriority)` constructor to be
`StdlibDeploymentTarget 5.9`
so the compiler will not complain when we reference it
from `ExecutorJob.createTrampoline` when building the standard library
without strict availability.
Addresses rdar://159397287
We were terminating after the first set of jobs; if one of them scheduled
another job, and there were no timers running, we would terminate,
which was wrong.
If a job enqueues another job on the executor, we might never leave
the inner `while` loop in the `run()` method. Fix this by taking
the contents of the run queue and only running those jobs in the
queue at the time we enter the inner loop.
I don't think we actually need this. If you have a non-canonical
(i.e. derived) clock, you can just implement `enqueue` and/or `run`
and call those methods on the clock you're wrapping.
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.
When using the new custom default executors, sometimes we end up
taking a long time to do a task switch. This is happening because
the path the new code takes sometimes results in a concrete pointer
to the default global executor being in the executor tracking
information in `swift_task_switch()`, and if we try to switch to
a `nil` task executor (which _also_ means the default global executor),
we aren’t spotting that and we’re taking the slow path.
Essentially, we want to take the fast path in cases where we switch
from `nil` to the concrete default global executor and vice-versa.
rdar://156701386
Concurrency from the Core project is importing the Darwin platform
overlay, which in turn depends on SwiftCore from the Core project,
breaking the project layering.
Concurrency only needs the Clang module, but Swift does not have a
mechanism to only import a clang module. For now import the
functionality needed from Darwin by importing and wrapping the
associated functions from `<dlfcn.h>` within `CFExecutor.cpp`
Also remove Darwin import from `AsyncStreamBuffer.swift` because it is
not used
`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.
