Ad-hoc requirements are now obsolete by making `remoteCall`,
`record{Argument, ReturnType}`, `decodeNextArgument` protocols
requirements and injecting witness tables for `SerializationRequirement`
conformances during IRGen.
Macro expansions are never considered implicit. They have
valid source locations in their macro expansion buffer, they
do not cause implicit 'self' capture diagnostics, etc. This
fixes an issue where existing code that iterates over an async
sequence in an escaping closure would diagnose a use of implicit
'self' via the '#isolation' argument to 'next()'.
Split distributed_actor_custom_executor_availability.swift into two tests, one
that only runs on existing platforms that support back deployment to Swift 5.7
aligned runtimes, and another test that is not restricted by platform that
tests behavior when deploying to a Swift 5.9 aligned runtime or later.
The distributed-actor-as-actor conformance is synthesized by the
frontend, so make sure that when we access the API that exposes it
(asLocalActor), we be sure to mark the conformance as "used".
This is a very specific workaround for general problem with
compiler-synthesized conformances. SIL deserialization can bring in a
reference to a conformance late in the SIL pipeline, after the point at
which SILGen can create the conformance. We should be able to address
this systemically to remove the hack.
When using `#isolation` within a context that is isolated to a
distributed actor, resolve to an `asLocalActor` access to retrieve the
local actor corresponding to the distributed actor.
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.
