Start implementing `nextElement()` for the various async sequences
provided by the concurrency library, starting with those that
currently depend on `rethrows` with conformances, an undocumented
feature we're trying to stage out of the language.
With the exception of `AsyncFlatMapSequence`, all of these async
sequences have obvious implementations of `nextElement()`. We'll save
that one for later.
This couples together several changes to move entirely from
`@rethrows` over to typed throws:
* Use the `Failure` type to determine whether an async for-each loop
will throw, rather than depending on rethrows checking
* Introduce a special carve-out for `rethrows` functions that have a
generic requirement on an `AsyncSequence` or `AsyncIteratorProtocol`,
which uses that requirement's `Failure` type as potentially being part
of the thrown error type. This allows existing generic functions like
the following to continue to work:
func f<S: AsyncSequence>(_: S) rethrows
* Switch SIL generation for the async for-each loop from the prior
`next()` over to the typed-throws version `_nextElement`.
* Remove `@rethrows` from `AsyncSequence` and `AsyncIteratorProtocol`
entirely. We are now fully dependent on typed throws.
Introduce a new associated type `Failure` into the two protocols involved
in async sequences, which represents the type thrown when the sequence
fails. Introduce a defaulted `_nextElement()` operations that throws
`Failure` or produces the next element of the sequence. Provide a
default implementation of `_nextElement()` in terms of `next()` that
force-cases the thrown error to the `Failure` type.
Introduce special associated type inference logic for the `Failure`
type of an `AsyncIteratorProtocol` conformance when there is no
specific _nextElement()` witness. This inference logic looks at the
witness for `next()`:
* If `next()` throws nothing, `Failure` is inferred to `Never`.
* If `next()` throws, `Failure` is inferred to `any Error`.
* If `next()` rethrows, `Failure` is inferred to `T.Failure`, where
`T` is the first type parameter with a conformance to either
`AsyncSequence` or `AsyncIteratorProtocol`.
The default implementation and the inference rule, together, allow
existing async sequences to continue working as before, and set us up
for changing the contract of the `async for` loop to use
`_nextIterator()` rather than `next()`.
Give `AsyncSequence` and `AsyncIteratorProtocol` primary associated
types for the element and failure types, which will allow them to be
used more generally with existential and opaque types.
This library uses GenericMetadataBuilder with a ReaderWriter that can read data and resolve pointers from MachO files, and emit a JSON representation of a dylib containing the built metadata.
We use LLVM's binary file readers to parse the MachO files and resolve fixups so we can follow pointers. This code is somewhat MachO specific, but could be generalized to other formats that LLVM supports.
rdar://116592577
a VarDecl or Expr.
This generalization exposed a bug where distributed actor isolation checking
was skipped in some cases, including for the isolated call in `whenLocal`.
The `whenLocal` implementation violated distributed actor isolation because
despite the `__isLocal` dynamic check, the `self` value passed to the `body`
function argument is still not statically local. To workaround this, I
applied the `_local` modifier explicitly to `self` before the call, which
also necessitated allowing `_local` to be written explicitly in the Distributed
library.
This patch introduces `--enable-experimental-noncopyable-generics` for
the build script. It replaces
`--swift-stdlib-experimental-noncopyable-generics`
The old build option only enables the feature when building the
stdlib, but if we've built the stdlib with NoncopyableGenerics, the
compiler should be hardwired to have that feature enabled, too.
This patch also introduces the `noncopyable_generics` lit parameter, so
that tests assuming the system was built with the feature can live
in-tree and be tested, if they specify `REQUIRES: noncopyable_generics`.
When an actual instance of a distributed actor is on the local node, it is
has the capabilities of `Actor`. This isn't expressible directly in the type
system, because not all `DistributedActor`s are `Actor`s, nor is the
opposite true.
Instead, provide an API `DistributedActor.asLocalActor` that can only
be executed when the distributed actor is known to be local (because
this API is not itself `distributed`), and produces an existential
`any Actor` referencing that actor. The resulting existential value
carries with it a special witness table that adapts any type
conforming to the DistributedActor protocol into a type that conforms
to the Actor protocol. It is "as if" one had written something like this:
extension DistributedActor: Actor { }
which, of course, is not permitted in the language. Nonetheless, we
lovingly craft such a witness table:
* The "type" being extended is represented as an extension context,
rather than as a type context. This hasn't been done before, all Swift
runtimes support it uniformly.
* A special witness is provided in the Distributed library to implement
the `Actor.unownedExecutor` operation. This witness back-deploys to the
Swift version were distributed actors were introduced (5.7). On Swift
5.9 runtimes (and newer), it will use
`DistributedActor.unownedExecutor` to support custom executors.
* The conformance of `Self: DistributedActor` is represented as a
conditional requirement, which gets satisfied by the witness table
that makes the type a `DistributedActor`. This makes the special
witness work.
* The witness table is *not* visible via any of the normal runtime
lookup tables, because doing so would allow any
`DistributedActor`-conforming type to conform to `Actor`, which would
break the safety model.
* The witness table is emitted on demand in any client that needs it.
In back-deployment configurations, there may be several witness tables
for the same concrete distributed actor conforming to `Actor`.
However, this duplication can only be observed under fairly extreme
circumstances (where one is opening the returned existential and
instantiating generic types with the distributed actor type as an
`Actor`, then performing dynamic type equivalence checks), and will
not be present with a new Swift runtime.
All of these tricks together mean that we need no runtime changes, and
`asLocalActor` back-deploys as far as distributed actors, allowing it's
use in `#isolation` and the async for...in loop.
The function is marked `noreturn` but the compiler was not able to reason
statically about whether this constraint is met. From code inspection it's
clear that the call to `swift_task_donateThreadToGlobalExecutorUntil()` does
not return, so `swift_unreachable()` can be used to suppress the warning.
It's harmless to have the protocol defined in the swiftinterface for
older compilers and removing the gating permits the gating to be omitted
from conformances
If `TypeRefVisitor<DemanglingForTypeRef, Demangle,NodePointer>::visit`
returns `nullptr`, we should pass it through. The callers of
`TypeRef::getDemangling()` are already prepared to cope with `nullptr`
returns, so this should be fine and avoids hitting an assertion
failure in that case.
rdar://120941628
We are currently lacking the ability to describe "normal or distributed
actor" with a single protocol in a manner that allows hopping to it,
because `AnyActor` is a marker protocol. Use `Actor` while we sort
this out.
This was originally attempted with https://github.com/apple/swift/pull/58810
but `_RegexParser` still ended up being built with library evolution enabled
because the `-enable-library-evolution` flag is added to the command line after
calling `add_swift_target_library` and therefore stripping the flag out of
`SWIFT_COMPILE_FLAGS` does nothing.
The `IS_FRAGILE` flag was introduced to support building C++ interop overlay
modules without library evolution and it can now be used to prevent
`_RegexParser` from being built with library evolution.
Resolves rdar://93067204
The `swift_unreachable()` is currently statically unreachable but we'd like to
leave it in place in case the control flow before it changes in the future.
