Given that `async` is the dominant way to initiate asynchronous work from
a synchronous function, speculatively rename `detach` to `asyncDetached`
to both fit into the naming scheme and clearly bias toward `async.
Also, do this for the initial slab for the task's allocator itself.
This avoids memory allocations for async-lets.
In case the async-task's memory demand does not exceed the initial slab size, it is now completely malloc-free.
The refcount bits of an async-let task are initialized to "immortal" so that ARC operations don't have an effect on the task.
SWIFT_CLASS_IS_SWIFT_MASK is optionally defined to a global variable _swift_classIsSwiftMask, which allows the runtime to choose the appropriate mask when running on OS versions earlier than macOS 10.14.4. This is no longer a supported target for newly built runtimes (Swift apps built with such a target will embed a copy of the back deployment runtime, which is separate) and this global is no longer useful. Instead, unconditionally define SWIFT_CLASS_IS_SWIFT_MASK to 2 on Apple platforms, which is the correct value for current OS versions.
rdar://48413153
The `async` operation is a global function that initiates asynchronous
work on behalf of the synchronous code that calls it. Unlike `detach`,
`async` inherits priority, actor context, and other aspects of the
synchronous code that initiates it, making it a better "default"
operation for creating asynchronous work than `detach`. The `detach`
operation is still important for creating truly detached tasks that
can later be `await`'d or cancelled if needed.
Implements the main entry point for rdar://76927008.
Commit the platform definition and build script work necessary to
cross-compile for arm64_32.
arm64_32 is a variant of AARCH64 that supports an ILP32 architecture.
The closure does not escape the startAsyncLet - endAsyncLet scope. Even though it's (potentially) running on a different thread.
The substantial change in the runtime is to not call swift_release on the closure context if it's a non-escaping closure.
For various reasons, it can be useful/interesting to create builds of
Swift that minimize dependencies. Let's try to keep that working as long
as we can.
This changed recently so that overflow and underflow consistently return signed
infinity or zero instead of nil. (Previously, overflow returned nil, underflow
returned zero.)
Among other benefits:
* The new behavior distinguishes malformed input (nil) from valid but out-of-range input.
* The new behavior preserves the sign of the input
* The new behavior is consistent with how floating-point parsing behaves in other langauges
Resolves rdar://76728925
An older Swift compiler failed to account for the witnesses in a
conformance with platform availability having their own availability,
which causes that compiler to reject the Swift module's .swiftinterface
file when it includes `AnyHashable` 's conformance to
`_HasCustomAnyHashableRepresentation`. Work around the issue by making
the one witness (`_toCustomAnyHashable`, which is trivial)
always-emit-into-client, so it does not need any availability.
Fixes rdar://76370138.
This patch plumbs through the ability to run async code in the standard
library unittests. The async start-point is `runAllTestsAsync` and must
be called from an async context. For now, that means calling through
async-main.
