This is done using a condition variable upon which the awaiting thread
will block if the continuation has not be resumed by the point of await.
The resuming thread will signal this condition variable, thereby
unblocking the awaiting thread.
Rdar://99977665
I keep trying to fix the tsan symbol dance, avoiding duplicate symbols
for initializing the tsan acquire and release function pointers. The
idea this time was to expose an API from the runtime to return the
function pointers for the compatibility library. This won't work because
the compatibility library would need to backdeploy to a version of the
library that doesn't have those symbols, so it would fail to link.
Now, if I really wanted to increment the counter again, an idea might be
to pull the swift_tsan_acquire/swift_tsan_release symbols out of the
Swift concurrency runtime and make them into a toolchain static library
which would get linked by the driver when doing an ASAN build. The
sanitizer libraries are already shipped like this, so it wouldn't be
too weird to do this.
This is required to a clang change. Attribute need to be in a certain order when building with a newer clang.
This fix might be replaced by something better, e.g. https://github.com/apple/swift/pull/61476
Rearrange the slow paths a bit to make them tail calls, which allows the compiler to emit these functions without frames.
Clang is happy to emit frameless functions on ARM64 if no stack space is needed on all execution paths. However, when there's a fast path which doesn't need stack space, and a slow path which does, clang emits code that pushes a stack frame and then decides which path to take. This is fine, but it means we're paying more than we'd like to on the fast path.
We can work around that by manually outlining the slow path, and ensuring that it's invoked with a tail call. Then the original function doesn't need a stack frame on any path and clang omits the stack frame.
We tweak RefCounts::increment to return the object it's being called on, which allows `swift_retain` to tail-call it. We manually outline the objc_retain call in swift_bridgeObjectRetain, which allows the swift_retain path to be frameless.
rdar://101764509
This addresses an unintended instance where new dispatch functionality
is not used on Windows as the lookup was never performed. This limits
the runtime to shared linking which should generally be a safe
assumption on Windows.
On ELF platforms we currently output an ELF note but with totally invalid
contents. I tried experimenting to see whether it was possible to do it
properly and tie the result into ReflectionContext, but it turns out to be a
hard problem because of issues to do with cross-segment symbol references and
relocations.
The upshot is that I think for now it's best just to remove it.
We might revisit this in future at some point; it would be good to be able to
reliably find the Swift metadata just from the ELF Phdrs.
rdar://101749382
This will help us to auto-generate conformances to `CxxRandomAccessCollection`, since synthesized conformances must have all of their witnesses explicitly provided.
This fixes a failure compiling the stdlib where the importer cannot find (i.e.,
refuses to import) functions _stdlib_remainderl and _stdlib_squareRootl.
We were detaching the child by just modifying the list, but the cancellation path was assuming that that would not be done without holding the task status lock.
This patch just fixes the current runtime; the back-deployment side is complicated.
Fixes rdar://88398824
These two modules themselves depend on modules that implicitly import the _StringProcessing library. Take OSLog as an example, which imports ObjectiveC, which implicitly imports _StringProcessing. Thus, we can get into the following bad scenario:
- A compiler at module format X builds _StringProcessing
- A rebase is performed and the compiler is rebuilt at module format Y > X
- OSLog builds before _StringProcessing (since it has no dependency)
- But _StringProcessing is at module format X < Y, so we have to rebuild it
This normally manifests as an error at the desks of compiler engineers about a mismatch in the module format for _StringProcessing. Let's fix that by making CMake schedule _StringProcessing before them.
