Previously there was still a sneaky hop which caused ordering issues.
This introduced a specific test startSynchronously_order which checks
that the task enqueues indeed are "immediate" and cleans up how we
handle this.
This also prepares for the being discussed in SE review direction of
this API that it SHOULD be ALLOWED to actually hop and NOT be
synchronous at all IF the isolation is specified on the closure and is
DIFFERENT than the callers dynamic isolation.
This effectively implements "synchronously run right now if dynamically
on the exact isolation as requested by the closure; otherwise enqueue
the task as usual".
resolves rdar://149284186
cc @drexin
(cherry picked from commit a24a28c217)
This fixes a deserialization failure in the compiler that occurred while loading the CxxStdlib overlay module:
```
Cross-reference to module 'Swift'
... Optional
... some
... with type <τ_0_0 where τ_0_0 : ~Copyable, τ_0_0 : ~Escapable> (Optional<τ_0_0>.Type) -> (τ_0_0) -> Optional<τ_0_0>
```
This was happening because the overlays were built against a different version of the Swift stdlib than is being used. The compiler is able to rebuild the Cxx and CxxStdlib modules from their textual interfaces. Let's use that feature unconditionally in production toolchains to avoid this kind of binary incompatibilities.
rdar://150416863
(cherry picked from commit 16b280862a)
Cherry-pick of #80547 for the 6.2 release branch.
---
Explanation: This cherry picks the implementation of SE-0477 to add a
string interpolation method with a `default:` parameter for optional
interpolation values.
Main Branch PR: https://github.com/swiftlang/swift/pull/80547
Risk: Low.
Reviewed By: @stephentyrone
Resolves: rdar://150865613
Testing: New tests for the string interpolations and fix-its.
This is basically the same as the one for Linux, but it would be
somewhat awkward to add the platform conditional on a file named for
Linux when OpenBSD is not Linux.
Important note: if Dispatch is disabled, then this will cause a
compilation error (probably not just for OpenBSD either), because
PlatformExecutorFactory is both defined in PlatformExecutorNone.swift
and PlatformExecutor<...>.swift in this case.
Because this only bites OpenBSD bootstrap builds, and since OpenBSD
support has been upstreamed to Dispatch, default to the Dispatch
implementation for now to get this in, and we'll refactor in a different
pr.
[Swiftify] Don't use count from Span inside withUnsafeBufferPointer c… (#81316)
Given a call like: ptr.withUnsafeBufferPointer { _ptrPtr in ... } ptr.count and _ptrPtr.count both contain the same value, but when ptr is a MutableSpan we get an error when referring to ptr inside a call to withUnsafeMutableBufferPointer, so we should use _ptrPtr.count instead.
rdar://150551109
[Swiftify] add _swiftifyOverrideLifetime for return Spans
std::span imports already have _cxxOverrideLifetime for their return
values. __counted_by needs the same, but Cxx may not be available at the
macro site, so we introduce _swiftifyOverrideLifetime in SwiftifyImport.
rdar://150569220
These TODOs aren’t particularly actionable. What we really want is a way to define `_overrideLifetime()` in a not-unsafe way, and that will probably be a `Builtin` operation.
We can always get it back from the git history.
rdar://150695113
(cherry picked from commit 9d59dbed17)
Conflicts:
include/swift/AST/DiagnosticsSema.def
include/swift/Basic/Features.def
test/abi/macOS/arm64/concurrency.swift
test/abi/macOS/x86_64/concurrency.swift
Dispatch uses unsigned times, and cannot cope with times before its
clock started. As such, passing negative times from Swift through to
the C++ code results in large unsigned values, which then causes us to
wait forever. This is undesirable.
rdar://148899609
I had originally thought that we'd get away without this because the
executor construction generally happens in the async `main` function,
but of course if a program doesn't already use Swift Concurrency,
and someone uses it from a plug-in or library it loads, there's a
risk that we might have a race condition.
rdar://149346132
... that would import that as a result of importing Darwin from the SDK.
Amend my previous change to Differentiation and Distributed in this
sense.
Addresses rdar://150400049
(cherry picked from commit 8c7e8550aa)
The use of SendableCompletionHandlers here is completely incidental,
because it happened to be introduced at roughly the same time as the
bits we needed for MutableSpan. Fixes rdar://148072153.
Swift concurrency defines a default platform executor. This was not
defined for FreeBSD resulting in build failures. Defining it to use the
Dispatch executor.
Scope: This only impacts FreeBSD.
Risk: Low. This change only affects FreeBSD.
Reviewers: @compnerd, @ktoso, @al45tair
Testing: Local testing to ensure Concurrency builds on FreeBSD.
Fixes: rdar://150643436
(cherry picked from commit 4a41e50730)
SE-0329 defines the following static factory methods:
```
public static func seconds<T: BinaryInteger>(_ seconds: T) -> Duration
public static func seconds(_ seconds: Double) -> Duration
public static func milliseconds<T: BinaryInteger>(_ milliseconds: T) -> Duration
public static func milliseconds(_ milliseconds: Double) -> Duration
public static func microseconds<T: BinaryInteger>(_ microseconds: T) -> Duration
public static func microseconds(_ microseconds: Double) -> Duration
public static func nanoseconds<T: BinaryInteger>(_ value: T) -> Duration
```
For no good reason, the obvious additional method:
```
public static func nanoseconds(_ nanoseconds: Double) -> Duration
```
was omitted. After talking this through with the LSG, we have decided
that this is simply a bug, and we will add this method without formal
evolution review.
We missed to sign the handler. Along the way the signature of it
changed, so adjust for that.
How to get the number:
```
func PROPER(bar: (TaskPriority, TaskPriority) -> Void) {
let p = TaskPriority.default
bar(p, p)
}
```
```
-> % swiftc -target arm64e-apple-macos13 example.swift -S -o - | swift demangle | grep -a3 autda
stur x8, [x29, #-64]
mov x17, x8
movk x17, #11839, lsl #48 <<<<<<<<<
autda x16, x17
ldr x8, [x16, #64]
lsr x8, x8, #0
add x8, x8, #15
```
Resolves rdar://150378890
If the preloaded status is locked, then we need to reload it in order to distinguish between the current thread holding the lock and another thread holding the lock. Without this, if another thread holds the lock, then we won't set the is-locked bit. We'll still actually hold the lock, but other threads may perform operations locklessly if the bit is not set, which can cause a crash. By reloading status in that case, we ensure that the bit is always set correctly.
This manifested as crashes in task cancellation but could cause other task-related issues as well.
Also remove an assert of !isStatusRecordLocked() in AsyncTask::complete(). We allow other threads to access tasks and take the lock for things like cancellation, so the lock may legitimately be held at that point.
rdar://150327908
(cherry picked from commit 325b66ab20)
We were failing to switch executors to Dispatch queues, where those
were being used as executors, which caused a variety of unusual
symptoms.
rdar://150310927
