We introduce a new macro called #SwiftSettings that can be used in conjunction
with a new stdlib type called SwiftSetting to control the default isolation at
the file level. It overrides the current default isolation whether it is the
current nonisolated state or main actor (when -enable-experimental-feature
UnspecifiedMeansMainActorIsolated is set).
Following the approach taken with the concurrency-specific type
descriptors, register a hook function for the "is current global actor"
check used for isolated conformances.
Extend the metadata representation of protocol conformance descriptors
to include information about the global actor to which the conformance is
isolated (when there is one), as well as the conformance of that type to
the GlobalActor protocol. Emit this metadata whenever a conformance is
isolated.
When performing a conforms-to-protocol check at runtime, check whether
the conformance that was found is isolated. If so, extract the serial
executor for the global actor and check whether we are running on that
executor. If not, the conformance fails.
The `swift_task_escalate` is defined to return the new priority of the
task after the escalation but the silgen_name'd function did not have
the return type specified.
Follow up to 18c25845d6
When it's available, use an open-coded allocator function that returns
an alloca without popping if the allocator is nullptr and otherwise
calls swift_coro_alloc. When it's not available, use the malloc
allocator in the synchronous context.
* [Concurrency] Initial steps for startSynchronously for Task
* [Concurrency] Rename to _startSynchronously while in development
* [Concurrency] StartSynchronously special executor to avoid switching
* startSynchronously bring back more info output
* [Concurrency] startSynchronously with more custom executor tests
* add missing ABI additions to test for x86
* [Concurrency] gyb generate _startSynchronously
* [Concurrency] %import dispatch for Linux startSynchronously test
* [Concurrency] Add TaskGroup.startTaskSynchronously funcs
* [Concurrency] DispatchSerialQueue does not exist on linux still
Previously these records were not used at all, so changing this has no
impact on existing runtimes. Note that we changedd the FunctionType
because the previous one was slightly incorrect -- the context comes
LAST in the type, not first.
The `-Winvalid-offsetof` warning is valid in this case. `offsetof` is
being applied to types with a non-standard layout. The layout of this
type is undefined by the specification. There is no guarantee that the
type layout is uniform across all ABIs. It is not possible to portably
compute the offset statically, especially efficiently.
Sink this check into a unit test to avoid performing this test at
runtime. In order to do this in the standard library, we would need to
do this check through a global constructor.
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
