* [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>
This is the last part to implement SE-0343. When `-warn-concurrency` is
passed to the compiler invocation, we want to protect top-level
variables behind the MainActor regardless of whether the top-level is an
asynchronous context. Note that this does not make the top-level an
asynchronous context, but it does annotate the top-level as being a
main-actor-protected context.
We used to concatenate the DeclContext's generic signature with the
protocol requirement's signature, then look for occurrences of the
first generic parameter from the DeclContext's signature in the
requirement's type.
This almost worked, except when the first generic parameter from the
DeclContext's signature didn't conform to a protocol referenced by
an associated type. In that case, we would falsely report that there
are no 'Self' references.
Note that the CHECK lines in test/SILGen/witnesses_class.swift change
to what they were before 01d9d61cc8.
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.
This is the transform that minimizes a protocol composition according
to generic signature rules, so for example P & C where C already
conforms to P will minimize down to just C.
Unfortunately this calls ASTContext::getOpenedArchetypeSignature(),
which is broken when the protocol composition involves a superclass
constraint containing an interface type.
For example, calling ASTContext::getOpenedArchetypeSignature() on
P & C<T> will build a signature
<Self where Self : P, Self : C<T>>
The generic parameter 'T' occurs as a "free variable", which is
invalid. What we ought to do is build a generic signature with the
outer parameters and requirements of the DeclContext where the
opened existential type appears, and then add 'Self' at the end
of the parameter list.
Until that is implemented, replace these calls with
getCanonicalType() to avoid triggering Requirement Machine
assertions.
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.
Ensure that we only open existentials in an argument when the corresponding
parameter's type is a generic parameter that is only used in covariant
positions, because either invariant or contravariant uses mean that we
won't be able to type-erase other uses of that parameter. This mirrors
the requirement placed when opening existentials as a member of protocol
type.
An opaque type is only invariant with respect to the existential Self
when the constraints on the opaque type involve Self. Such constraints
are not expressible in the type-erased value, so treat them as
invariant. This loosens the restriction on using members of protocol
type that return an opaque type, such that (e.g.) the following is
still well-formed:
protocol P { }
protocol Q { }
extension P {
func getQ() -> some Q { ... }
}
func test(p: any P) {
let q = p.getQ() // formerly an error, now returns an "any Q"
}
However, this does not permit uses of members such as:
extension P {
func getCollection() -> some Collection<Self> { ... } // error
}
because the type system cannot express the corresponding existential
type `any Collection<Self>`.
The RequirementSignature generalizes the old ArrayRef<Requirement>
which stores the minimal requirements that a conforming type's
witnesses must satisfy, to also record the protocol typealiases
defined in the protocol.
The distributed case is distinguishable from the non-distributed case
based on the actor type itself for those rare cases where we care. The
vast majority of code is simplified by treating this identically to
`ActorInstance`.
As part of SE-327, global-actor isolation applied to
the instance-stored properties of a value type do
not require any isolation, since there is no way to
create a race on access to that storage.
https://github.com/apple/swift-evolution/blob/main/proposals/0327-actor-initializers.md#removing-redundant-isolation
This change turns global-actor annotations on such
properties into an error in Swift 6+, and a warning
in Swift 5 and earlier.
In addition, inference for global-actor isolation
no longer applies global-actor isolation to such
properties. Since this latter change only results
in warnings in existing Swift 5 code, about a now
superflous 'await', this change will happen in
Swift 5+.
Fixes rdar://87568381
Flow-isolation is a diagnostic SIL pass that finds
unsafe accesses to properties in initializers and
deinitializers that cannot gain isolation to otherwise
protect those accesses from concurrent modifications.
See SE-327 for more details about how and why it exists.
This commit includes changes and features like:
- The removal of the escaping-use restriction
- Flow-isolation that works properly with `defer` statements
- Flow-isolation with an emphasis on helpful diagnostics.
It also includes known issues like:
- Local / nonescaping functions are not analyzed by
flow-isolation, despite it being technically possible.
The main challenge in supporting it efficiently is that
such functions do not have a single exit-point, like
a `defer`. In particular, arbitrary functions can throw
so there are points where nonisolation should _not_ flow
out of the function at a call-site in the initializer, etc.
- The implementation of the flow-isolation pass is not
particularly memory efficient; it relies on BitDataflow
even though the particular flow problem is simple.
So, a more efficient implementation would be specialized for
this particular problem, etc.
There are also some changes to the Swift language itself: defer
will respect its context when deciding its property access kind.
Previously, a defer in an initializer would always access a stored
property through its accessor methods, instead of doing so directly
like its enclosing function might. This inconsistency is unfortunate,
so for Swift 6+ we make this consistent. For Swift 5, only a defer
in a function that is a member of the following kinds of types
will gain this consistency:
- an actor type
- any nominal type that is actor-isolated, excluding UnsafeGlobalActor.
These types are still rather new, so there is much less of a chance of
breaking expected behaviors around defer. In particular, the danger is
that users are relying on the behavior of defer triggering a property
observer within an init or deinit, when it would not be triggering it
without the defer.
Control 'async' variant of imported ObjC methods.
For non-'async' variant:
1) if 'swift_private' is specified, hide.
For 'async' variant:
1) if 'swift_async(swift_private)' is specified, hide.
2) if 'swift_async(not_swift_private)' is specified, show.
3) if 'swift_async_name()' is specified, show.
4) if 'swift_private' is specified, hide.
rdar://80602940
This patch replaces the use of the experimental-async-top-level flag
with checking the decl context of the top-level variable to determine
whether the top-level contexts should be async.
