Rather than write an appoximation of the "is distributed thunk" check
within the type checker, use the new actor reference checking logic with
a referenced actor that is synthesized from the information in the
constraint system.
Start collapsing the several implementations of actor isolation checking
into a single place that determines what it means to reference a declaration
from a given context, potentially supplying an instance for an actor. This
is partly cleanup, and partly staging for the implementation of the
Sendable restrictions introduced in SE-0338. The result of this check
falls into one of three categories:
* Reference occurs within the same concurrency domain (actor/task)
* Reference leaves an actor context to a nonisolated context (SE-0338)
* Reference enters the context of the actor, which might require a
combination of implicit async, implicit throws, and a "distributed" check.
Throughout this change I've sought to maintain the existing semantics,
even where I believe they are incorrect. The changes to the test cases
are not semantic changes, but reflect the unification of some
diagnostic paths that changed the diagnostic text but not when or how
those diagnostics are produced. Additionally, SE-0338 has not yet been
implemented, although this refactoring makes it easier to implement
SE-0338.
Use this new actor isolation checking scheme to implement the most
common actor-isolation check, which occurs when accessing a member of
an instance.
While synthesizing `~=` application for multi-statement closures or
result builder, solver shouldn't set types directly to newly
created AST nodes because they might not be fully resolved, instead
such types have to be recorded in the constraint system and then
set during solution application.
Resolves: rdar://91145060.
`ExprRewriter` could be created for a solution application target,
which could have its own declaration context if it's e.g. an inner
statement or a pattern binding.
Implicit casts are allowed to provide cast type directly without
a type repr, adjust solution application logic to handle this just
like constraint generator does. Also fix a couple of places where
declaration context from constraint system was used instead
of one associated with the expression rewriter.
Solution application target can have its declaration context differ
from one used for constraint system, since target could be e.g. a
pattern associated with pattern binding declaration, a statement or
a sub-element of one (e.g. where clause) used in a closure etc.
* [Distributed] dist actor always has default executor (currently)
* [Distributed] extra test for missing makeEncoder
* [DistributedDecl] Add DistributedActorSystem to known SDK types
* [DistributedActor] ok progress on getting the system via witness
* [Distributed] allow hop-to `let any: any X` where X is DistActor
* [Distributed] AST: Add an accessor to determine whether type is distributed actor
- Classes have specialized method on their declarations
- Archetypes and existentials check their conformances for
presence of `DistributedActor` protocol.
* [Distributed] AST: Account for distributed members declared in class extensions
`getConcreteReplacementForProtocolActorSystemType` should use `getSelfClassDecl`
otherwise it wouldn't be able to find actor if the member is declared in an extension.
* [Distributed] fix ad-hoc requirement checks for 'mutating'
[PreChecker] LookupDC might be null, so account for that
* [Distributed] Completed AST synthesis for dist thunk
* [Distributed][ASTDumper] print pretty distributed in right color in AST dumps
* wip on making the local/remote calls
* using the _local to mark the localCall as known local
* [Distributed] fix passing Never when not throwing
* fix lifetime of mangled string
* [Distributed] Implement recordGenericSubstitution
* [Distributed] Dont add .
* [Distributed] dont emit thunk when func broken
* [Distributed] fix tests; cleanups
* [Distributed] cleanup, move is... funcs to DistributedDecl
* [Distributed] Remove SILGen for distributed thunks, it is in Sema now!
* [Distributed] no need to check stored props in protocols
* remote not used flag
* fix mangling test
* [Distributed] Synthesis: Don't re-use AST nodes for `decodeArgument` references
* [Distributed] Synthesis: Make sure that each thunk parameter has an internal name
* [Distributed/Synthesis] NFC: Add a comment regarding empty internal parameter names
* [Distributed] NFC: Adjust distributed thunk manglings in the accessor section test-cases
* cleanup
* [Distributed] NFC: Adjust distributed thunk manglings in the accessor thunk test-cases
* review follow ups
* xfail some linux tests for now so we can land the AST thunk
* Update distributed_actor_remote_functions.swift
Co-authored-by: Pavel Yaskevich <xedin@apache.org>
Represent this in much the same way that collections do by creating an opaque value representing the source argument, and a conversion expression representing the destination argument.
This ensures that opened archetypes always inherit any outer generic parameters from the context in which they reside. This matters because class bounds may bind generic parameters from these outer contexts, and without the outer context you can wind up with ill-formed generic environments like
<τ_0_0, where τ_0_0 : C<T>, τ_0_0 : P>
Where T is otherwise unbound because there is no entry for it among the generic parameters of the environment's associated generic signature.
Augment the constraint solver to fallback to implicit `~=` application
when member couldn't be found for `EnumElement` patterns because
`case` statement should be able to match enum member directly, as well
as through an implicit `~=` operator application.
We used to incorrectly forward inout paramters in the thunk for both template paramters that aren't used in the signature and in the thunk for dependent types as Any.
Now this works in the simple case. We'll need to do something more complicated when we have an `inout Any` for dependent types because we will need to somehow cast without copying. This will probably require synthesising the SIL of the thunk manually.
When a closure is not properly actor-isolated, but we know that we inferred its isolation from a `@preconcurrency` declaration, we now emit the errors as warnings in Swift 5 mode to avoid breaking source compatibility if the isolation was added retroactively.
When calling a generic function with an argument of existential type,
implicitly "open" the existential type into a concrete archetype, which
can then be bound to the generic type. This extends the implicit
opening that is performed when accessing a member of an existential
type from the "self" parameter to all parameters. For example:
func unsafeFirst<C: Collection>(_ c: C) -> C.Element { c.first! }
func g(c: any Collection) {
unsafeFirst(c) // currently an error
// with this change, succeeds and produces an 'Any'
}
This avoids many common sources of errors of the form
protocol 'P' as a type cannot conform to the protocol itself
which come from calling generic functions with an existential, and
allows another way "out" if one has an existention and needs to treat
it generically.
This feature is behind a frontend flag
`-enable-experimental-opened-existential-types`.
Dependent types are going to be very hard to support, especially in complex cases. This PR adds a workaround that people can use: `Any`. This requires manual type casting, but it does work.
