These metatypes are a gateway to more incorrect
uses of these noncopyable values because we don't
yet have the corresponding runtime support yet.
The other use cases of using metatypes of
noncopyable types in generics is not high enough to
warrant people using them yet.
resolves rdar://106452518
Revert a few unnecessary changes have been made to the _Concurrency module
recently that make its swiftinterface un-parseable by older compilers that we
need to support.
- The `consume` keyword is not understood by older compilers, so including it
in inlinable code is a problem. It has no actual effect on lifetimes where it
was used, so just omit it.
- Don't build the _Concurrency module with -enable-experimental-feature
MoveOnly. The MoveOnly feature is now enabled by default in recent compilers,
so the flag is superfluous when building the dylib. When emitting the
interface, having the feature enabled explicitly exposes code guarded by
`$MoveOnly` to older compilers that do not accept all of the code.
Resolves rdar://108793606
Because `_taskLocalValuePush` and `_taskLocalValuePop` can result in calls
to `swift_task_alloc` and `swift_task_dealloc` respectively, and because
the compiler hasn't been taught about that (e.g.
`SILInstruction::isAllocatingStack`,
`SILInstruction::isDeallocatingStack`, etc), calling them (push and pop)
from a function which makes use the stack for dynamically sized
allocations can result in violations of stack discipline of the form
```
swift_task_alloc // allocates %ptr_1
copy_value_witness // copies into %ptr_1
swift_task_localValuePush // calls swift_task_alloc and allocates %ptr_2
swift_task_dealloc // deallocates %ptr_1
swift_task_localValuePop // calls swift_task_dealloc and deallocates %ptr_2
```
Avoid the problem by not allocating dynamically sized stack space in the
function which calls `_taskLocalValuePush` and `_taskLocalValuePop`.
Split the calls to those functions into `withValueImpl` function which
takes its argument `__owned`. Call that function from `withValue`,
ensuring that the necessary copy (to account for the fact that withValue
takes its argument `__guaranteed` but `_taskLocalValuePush` takes its
`__owned`) and associated stack traffic occur in `withValue`.
Still, allow `withValueImpl` to be inlined. The stack nesting will be
preserved across it.
rdar://107275872
startOnMainActor checked the current executor directly, which in some
cases came back as a `nullptr`. This happens with older API which don't
know to set the current executor. `swift_task_isCurrentExecutor` knows
how to check for the current dispatch queue and the main thread though,
so switching the main-executor check to use that API instead.
We ran into an issue on minimal stdlib build configurations, because they
pull slightly older toolchains to build and test the stdlib. The noncopyable
`Job` type was adopted immediately after such types were enabled by default,
before the toolchain builds could catch up. Adding this flag to the build of
the `_Concurrency` lib should make things more robust when somewhat older
compilers are building this part of the stdlib.
part of resolving rdar://106849189
* [Executors][Distributed] custom executors for distributed actor
* harden ordering guarantees of synthesised fields
* the issue was that a non-default actor must implement the is remote check differently
* NonDefaultDistributedActor to complete support and remote flag handling
* invoke nonDefaultDistributedActorInitialize when necessary in SILGen
* refactor inline assertion into method
* cleanup
* [Executors][Distributed] Update module version for NonDefaultDistributedActor
* Minor docs cleanup
* we solved those fixme's
* add mangling test for non-def-dist-actor
We say in a comment here that we print the error and cancel, but we don't actually have the print below. This PR adds that missing print in the docs snippet.
Looks like simply putting the availability attribute on the extension
does not suffice. Putting the availability attr on the function itself
to appease the api-digester.
This patch adds an SPI to run the first partial function of a MainActor
asynchronous function on the MainActor synchronously. This is
effectively like the asynchronous program entrypoint behavior. The first
partial function is run synchronously. Following continuations are
enqueued for execution like any other asynchronous function.
Verifying that the ANSI color control sequences don't show up in CI
logs. AsyncStreamBuffer.swift emits warnings, so dirtying it will ensure
it gets rebuilt in CI.
