Stripping out the logic behind enabling concurrency tracing
independently of the rest of the standard library tracing. It's not
clear that there is a use-case where we want one without the other.
Switching the concurrency runtime to use the common SWIFT_STDLIB_TRACING
to control whether the concurrency runtime enables tracing. The old
process required passing bot the `SWIFT_STDLIB_TRACING` and
`SWIFT_STDLIB_CONCURRENCY_TRACING` macro to the concurrency build or it
would fail to build.
It's not clear that there are any environments where it is desirable
for swiftCore to have tracing enabled and not have swift_Concurrency
tracing enabled or vice versa. Replacing the concurrency-specific macro
with a single common macro. If it is desirable, we can teach the build
system to avoid passing `SWIFT_STDLIB_TRACING` to a specific target if
an option is not set.
rdar://165777240
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
