Remove the multiple definitions of `std::bit_cast` into a header. While
this is still not great, it does reduce the duplication. This also
silently works towards reducing a bit of the UB introduced here by
adding an inline namespace for `std` which you are not technically
allowed to use. However, by doing this, we have a clear migration path
away from this once we adopt C++20.
The C++ standard does not guarantee that the code and data pointers are
interchangeable. Recent enhancements to clang now properly identify the
improper `reinterpret_cast` between function types. Silence the warning
by switching to `std::bit_cast`. Unfortunately, this is a C++20 feature
and we are still on C++17. In the case that the compiler doesn't have a
`bit_cast` implementation, fallback with some UB to a local definition.
In the Dispatch implementation, clamp the delay to INT64_MAX. Swift's nanoseconds value is unsigned, but we ultimately use it with dispatch_time, which takes a signed int64_t. Extremely large values get interpreted as negative, which results in not sleeping.
INT64_MAX nanoseconds is about 292 years, so it should be difficult to notice a practical effect from sleeping for less time than requested due to the clamping.
rdar://143278824
Our Bazel builds have become more strict about libc++
dependencies recently, so these are required to pick up
declarations of `malloc` and `uint32_t`, respectively.
The magic symbols specify a version range where clients should reference a @rpath relative path to libswift_Concurrency.dylib instead of the standard absolute path. This version range started at macOS 10.15 and aligned versions, which is the oldest target supported by Concurrency. However, clients that use Concurrency can target earlier OSes as long as they availability-check their use of Concurrency. When targeting something earlier than 10.15, they'd reference the absolute path, then fail to find the back-deployment Concurrency runtime on OS versions that need it.
Fix this by setting the start of the range to macOS 10.9 and aligned, which is the oldest target supported by Swift.
rdar://140476764
In Embedded Swift, the `String` type is unavailable. This means that the
overload of `fatalError()` that takes a `String` is also unavailable. Specify a
`StaticString` in the setter for `TaskLocal.projectedValue` to satisfy this
constraint.
We should build a 64-bit value from the two 32-bit Id fields, but we were shifting one field by the other. Coincidentally, this managed to produce the correct value until the ID goes beyond 2^32, but after that it's weird and wrong.
There cannot be undefined behavior at compile time, so these warnings can be
ignored when `offsetof` is used in a static assert:
```
warning: offset of on non-standard-layout type 'AsyncTask' [-Winvalid-offsetof]
```
Replace NextLinkType with Item::Kind with more clear definition.
Use llvm::PointerIntPair<>.
Use hierarchy of classes instead of optional fields inside Item.
Combined Storage::copyToOnlyOnlyFromCurrentGroup() into Storage::initializeLinkParent().
Also create parent task marker when copying items created inside withTaskGroup().
Removed Storage::peekHeadLinkType().
This routine takes a synchronous non-throwing main actor isolated closure
without a result. If we are dynamically on the main actor, we just run the
closure synchronously. Otherwise, we run a new task on the main actor and call
the closure on that.
This builds on top of the previous commit by using
swift_task_isCurrentExecutorWithFlags in the implementation of this function.
To backwards deploy this function on Darwin, I used some tricks from libdispatch
to validate that we are on the main queue.
This entrypoint is similar to swift_task_isCurrentExecutor except that it
provides an ABI level option flag that enables one to configure its behavior in
a backwards deployable manner via the option flag.
I used this to expose at the ABI level the ability to check the current executor
without crashing on failure, while preserving the current behavior of
swift_task_isCurrentExecutor (which crashes on failure).
I am going to use this to implement swift_task_runOnMainActor.
It's possible that the job we enqueue holds the last strong reference to the actor. If that job runs on another thread after we enqueue it, then it's possible for `this` to be destroyed while we're still in this function. We need to use `this` after the enqueue when the priorities don't match. When it looks like that will happen, retain `this` before the enqueue to ensure it stays alive until we're done with it.
Introduce a defensive retain helper class that makes it easy to do a single retain under certain conditions even in a loop, and does RAII to balance it with a release when the scope exits.
rdar://135400933
In embedded mode, we mustn't have references to the C++ library, because
some embedded platforms don't include the C++ library.
Additionally, it's good to avoid use of global operator new and operator
delete, because they can be globally overridden and this has bitten us
in the past.
rdar://137286187
We have been only including a subset of files and functionality on Embedded Concurrency, let's instead include all the
source files, and have a fine grained opt out on things that don't yet work. Namely, this is still avoiding clocks, task
sleeping and custom executors.
Add a test for AsyncStream and continuations on Embedded Concurrency.
