The main effect of this change is that diagnostics about Sendable
conformances now follow the same minimal/full logic used for other
Sendable diagnostics, rather than having their own separate
computation.
With the change I made to say that synchronous actor inits
that are otherwise not isolated to anything else should be `nonisolated`,
we lost the Sendable checking on its parameters.
This patch brings that back by enforcing a CrossActorSelf restriction
for accesses to such decls, despite them having `nonisolated` isolation.
We previously had a bug where `@Sendable` would not be propagated to a
closure when that closure was assigned to a property or passed to a
parameter of optional `@Sendable` function type. This has already been
fixed in the type checker, but add a test to ensure that we don't
regress this behavior. rdar://77789778
Extend the diagnostics for `Sendable` conformances to always diagnose
missing `Sendable` conformances for nominal types that are within the
same module. The intuition here is that if the type is in the same
module, it can be updated and evaluated at the same time as code
requiring the `Sendable` conformance is introduced.
Another part of rdar://78269348.
Rework Sendable checking to be completely based on "missing"
conformances, so that we can individually diagnose missing Sendable
conformances based on both the module in which the conformance check
happened as well as where the type was declared. The basic rules here
are to only diagnose if either the module where the non-Sendable type
was declared or the module where it was checked was compiled with a
mode that consistently diagnoses `Sendable`, either by virtue of
being Swift 6 or because `-warn-concurrency` was provided on the
command line. And have that diagnostic be an error in Swift 6 or
warning in Swift 5.x.
There is much tuning to be done here.
Parse and provide semantic checking for '@unchecked Sendable', for a
Sendable conformance that doesn't perform additional semantic checks
for correctness.
Part of rdar://78269000.
A nonisolated declaration is accessible concurrently, so it must be of
Sendable type to be safe. This plugs a hole in data-race preventation
that will need to be documented in an amendment to SE-0313.
Check actor isolation of calls to functions with global-actor-qualified
type. This closes a pre-existing loophole where a value of
global-actor-qualified function type could be called from any context.
Paired with this, references to global-actor-qualified function
declarations will get global-actor-qualified function type whenever
they are referenced within an experience, i.e., whenever we form a
value of that type. Such references can occur anywhere (one does not
need to be on the actor), and carrying the global actor along with the
function type ensures that they can only be called from the right
actor. For example:
@MainActor func onlyOnMainActor() { ... }
func callIt(_ fn: @MainActor () -> Void) {
fn() // error: not on the main actor, so cannot synchronously call
// this wasn't previously diagnosed
}
func passIt() {
callIt(onlyOnMainActor) // okay to pass the function
// used to be an error
}
While here, fix up some broken substitution logic for
global-actor-qualified function types and "override" actor isolation.
Introduce the notion of "unsafe" @Sendable parameters, indicated by the
hidden @_unsafeSendable parameter attribute. Closure arguments to such
parameters are treated as @Sendable within code that has already
adopted concurrency, but are otherwise enert, allowing them to be
applied to existing concurrency-related APIs to smooth the transition
path to concurrency.
Additionally, introduce the notion of an "unsafe" @MainActor closure,
for cases where we have determined that the closure will execute on
the main actor but it (also) isn't part of the type system.
Pattern-match uses of the Dispatch library's DispatchQueue to infer
both kinds of "unsafe" as appropriate, especially (e.g.) matching the pattern
DispatchQueue.main.async { ... }
to treat the closure as unsafe @Sendable and @MainActor, allowing such
existing code to better integrate with concurrency.
Implements rdar://75988966.
One cannot introduce ConcurrentValue conformance on a class
that has a (non-NSObject) superclass, nor put a ConcurrentValue
conformance on an open class.
We're not quite ready to commit to the flow-sensitive check that would
allow a concurrent function to read from a mutable local capture so
long as the captured variable wasn't changed after the point of
capture. Put it behind a flag and implement the more restrictive rule
(no access to mutable local captures in concurrent code). We can relax
it later.
Thanks to Jordan Rose and John McCall, who pointed out why this checking was unnecessary.
As a drive-by, ensure that we diagnose parameter references properly.
This patch updates the `actor class` spelling to `actor` in almost all
of the tests. There are places where I verify that we sanely handle
`actor` as an attribute though. These include:
- test/decl/class/actor/basic.swift
- test/decl/protocol/special/Actor.swift
- test/SourceKit/CursorInfo/cursor_info_concurrency.swift
- test/attr/attr_objc_async.swift
- test/ModuleInterface/actor_protocol.swift
Initializers are actor-isolated when they are part of an actor or have
a global actor. However, uses of actor initializers need to be treated
as cross-actor references so we proper `ConcurrentValue` checking for
values passed into the initializer.
Fixes rdar://74064751.
Introduce checking of ConcurrentValue conformances:
- For structs, check that each stored property conforms to ConcurrentValue
- For enums, check that each associated value conforms to ConcurrentValue
- For classes, check that each stored property is immutable and conforms
to ConcurrentValue
Because all of the stored properties / associated values need to be
visible for this check to work, limit ConcurrentValue conformances to
be in the same source file as the type definition.
This checking can be disabled by conforming to a new marker protocol,
UnsafeConcurrentValue, that refines ConcurrentValue.
UnsafeConcurrentValue otherwise his no specific meaning. This allows
both "I know what I'm doing" for types that manage concurrent access
themselves as well as enabling retroactive conformance, both of which
are fundamentally unsafe but also quite necessary.
The bulk of this change ended up being to the standard library, because
all conformances of standard library types to the ConcurrentValue
protocol needed to be sunk down into the standard library so they
would benefit from the checking above. There were numerous little
mistakes in the initial pass through the stsandard library types that
have now been corrected.
When referring to an actor-isolated declaration from outside of the
actor, ensure that the types involved conform to the `ConcurrentValue`
protocol. Otherwise, produce a diagnostic stating that it is unsafe to
pass such types across actors.
Apply the same rule to local captures within concurrent code.
