1. Non-actor initializers should participate in custom default isolation
inference. Otherwise, they will not be able to touch the type's stored
properties to initialize them if those properties have the default
isolation inferred.
2. All declarations inside actors and distributed actors do not participate
in default isolation inference; they remain unspecified, so the existing
isolation inference rules apply.
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
I also added a small runtime test just as a sanity check. We do not change any
codegen here since the change is at the Sema level... but I thought it would be
prudent to at least have a small smoke test.
rdar://140439795
Sendable violations inside `@preconcurrency @Sendable` closures should be
suppressed in minimal checking, and diagnosed as warnings under complete
checking, including the Swift 6 language mode.
Find all the usages of `--enable-experimental-feature` or
`--enable-upcoming-feature` in the tests and replace some of the
`REQUIRES: asserts` to use `REQUIRES: swift-feature-Foo` instead, which
should correctly apply to depending on the asserts/noasserts mode of the
toolchain for each feature.
Remove some comments that talked about enabling asserts since they don't
apply anymore (but I might had miss some).
All this was done with an automated script, so some formatting weirdness
might happen, but I hope I fixed most of those.
There might be some tests that were `REQUIRES: asserts` that might run
in `noasserts` toolchains now. This will normally be because their
feature went from experimental to upcoming/base and the tests were not
updated.
Use the `%target-swift-5.1-abi-triple` substitution to compile the tests for
deployment to the minimum OS versions required for use of _Concurrency APIs,
instead of disabling availability checking.
Instead, use the `%target-swift-5.1-abi-triple` substitution to compile the tests
for deployment to the minimum OS versions required for use of _Concurrency APIs.
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.
The test only checks Task done and then "deinit" happening, however
there is another print that may happen in between. Since it's racy which
one comes first, on slower instances -- like simulators, it could get in
the way.
Remove the println we're not even checking for but that breaks the
CHECK-NEXT
Resolves rdar://137221764
As of the changes in https://github.com/swiftlang/swift/pull/41713 to
enable Sendability for AsyncStream, it has been possible to create
multiple stream consumers operating concurrently. This change fixes
behavior in the case that the underlying stream is terminated while
multiple pending continuations are outstanding. Previously such
consumers would have been leaked (never resumed). Now, they are notified
of the stream's termination and resumed appropriately.
Resolves#66541 & #71412
* [Concurrency] Fix task excutor handling of default actor isolation
The task executor API did not properly account for taking the default
actor locking into account when running code on it, we just took the job
and ran it without checking with the serial executor at all, which
resulted in potential concurrent executions inside the actor --
violating actor isolation.
Here we change the TaskExecutor enqueue API to accept the "target"
serial executor, which in practice will be either generic or a specific
default actor, and coordinate with it when we perform a
runSynchronously.
The SE proposal needs to be amended to showcase this new API, however
without this change we are introducing races so we must do this before
the API is stable.
* Remove _swift_task_enqueueOnTaskExecutor as we don't use it anymore
* no need for the new protocol requirement
* remove the enqueue(_ job: UnownedJob, isolatedTo unownedSerialExecutor: UnownedSerialExecutor)
Thankfully we dont need it after all
* Don't add swift_defaultActor_enqueue_withTaskExecutor and centralize the task executor getting to enqueue()
* move around extern definitions
The test is checking that the task executor deinit runs after task
completes. This deinit is caused on a different thread, and thus is
racing with the main() completing. This is racy because as main() exits,
we just exit the process and may not see the deinit get printed, making
the test look like the deinit "didnt trigger" but it did, just was
"late to the party"
resolves rdar://130528198
It could be confusing to adopters who were led to believe by the types
that they should "just" implement the sharedUnownedExecutor property,
but insead they have to implement the unownedExecutor on the specific
actor type.
Adding documentation clarify this as well as a simple test that
exercises this explicitly; We seem to have much coverage of main actor,
but not so much of custom executor global actors.
