This should correspond to the definition of memcmp in
usr/include/string.h and keep it from being a source of confusion for
the compiler.
rdar://69876253
This allows programs to target older OSes while using Concurrency behind an availability check. When targeting older OSes, the symbols are weak-linked and the compiler will require the use of Concurrency features to be guarded by an availability check.
rdar://75850003
This extension (introduced in https://github.com/apple/swift/pull/35264) was placed in a file location where it wasn’t correctly guarded against mentioning Float16 on macOS/x86_64, so the generated .swiftinterface file included a reference to an unavailable declaration. (The dummy stand-in Float16 type that we currently use on Intel macOS.)
Moving the declaration out of the “AnyHashable” section and into a file region that’s more suitable for it (i.e., enclosed in `#if !((os(macOS) || targetEnvironment(macCatalyst)) && arch(x86_64))`) resolves the issue.
rdar://76025365
* Move differentiability kinds from target function type metadata to trailing objects so that we don't exhaust all remaining bits of function type metadata.
* Differentiability kind is now stored in a tail-allocated word when function type flags say it's differentiable, located immediately after the normal function type metadata's contents (with proper alignment in between).
* Add new runtime function `swift_getFunctionTypeMetadataDifferentiable` which handles differentiable function types.
* Fix mangling of different differentiability kinds in function types. Mangle it like `ConcurrentFunctionType` so that we can drop special cases for escaping functions.
```
function-signature ::= params-type params-type async? sendable? throws? differentiable? // results and parameters
...
differentiable ::= 'jf' // @differentiable(_forward) on function type
differentiable ::= 'jr' // @differentiable(reverse) on function type
differentiable ::= 'jd' // @differentiable on function type
differentiable ::= 'jl' // @differentiable(_linear) on function type
```
Resolves rdar://75240064.
The previous fix here switched dyn_cast for dyn_cast_or_null, but this left us with an assertion failure in cast<>. Instead, explicitly check for NULL at the top of the function.
The immediate desire is to minimize the set of ABI dependencies
on the layout of an ExecutorRef. In addition to that, however,
I wanted to generally reduce the code size impact of an unsafe
continuation since it now requires accessing thread-local state,
and I wanted resumption to not have to create unnecessary type
metadata for the value type just to do the initialization.
Therefore, I've introduced a swift_continuation_init function
which handles the default initialization of a continuation
and returns a reference to the current task. I've also moved
the initialization of the normal continuation result into the
caller (out of the runtime), and I've moved the resumption-side
cmpxchg into the runtime (and prior to the task being enqueued).
Fill out the metadata for Job to have a Dispatch-compatible vtable. When available, use the dispatch_enqueue_onto_queue_4Swift to enqueue Jobs directly onto queues. Otherwise, keep using dispatch_async_f as we have been.
rdar://75227953
It saved some boilerplate, but if it doesn't get inline (as in debug builds), Swift doesn't know how to legalize the type at the call boundary, and we crash.
* Replace lhs/rhs with a/b for clarity of documentation and to match concrete ops.
* Concretize additional SIMDMask operations:
.&=, .|=, .^=, .==, .!=
Also reflect documentation changes back to generic implementations.
Somehow, clang was generating code that accepted nil and returned nil in swift_getObjCClassFromMetadata, but is no longer doing so. Some code relies on this to work, so switch to dyn_cast_or_null to accept nil explicitly.
rdar://74895271
