This is possible because actors do not support inheritance. There
is one specific exception to that rule, which is that an actor
can inherit from `NSObject` just to support ObjC interop.
This means an actor is effectively a final class.
resolves rdar://87568153
`isConcurrencyChecked()` was being used as a proxy for
`-warn-concurrency` that didn't account for Swift 6. Replace
checks against it within the current module with checks against the
strict concurrency level, which subsumes the Swift 6 check and can
account for the difference between "limited" and "on".
`isConcurrencyChecked()` is used now used exclusively to mean "treat a
missing Sendable conformance as an explicitly-non-Sendable type".
There were some tests that relied on the top-level code not being an
asynchronous context to emit certain error messages. Now that it is,
those tests weren't emitting the expected error message.
In other cases, the issue was that they were trying to initialize a
global variable and weren't really using top-level code as top-level
code, so adding `-parse-as-library` was sufficient for the testing
purposes.
To fix the objc_async test, parsing as a library was nearly sufficient.
Unfortunately, the little `if #available` trick that I was using stopped
working since it relied on being in top-level code. So that we emit the
unavailableFromAsync error message, I had to set the availability on
everything correctly because we can't just disable availability
checking.
This is a combination of fixes:
- inject hops in self-isolated delegating actor initializers
after self becomes initialized.
- fix sendable and isolation for convenience inits
- fix bug in distributed actor inits that I introduced when
implementing flow-isolation.
- fix / add test coverage.
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.
Introduce the `@preconcurrency` attribute name for `@_predatesConcurrency`,
which has been the favored name in the pitch thread so far. Retain the
old name for now to help smooth migration.
Rather than only checking the sendability of captures at the point of
use, diagnose captures uniformly for the closure as a whole. Fixes a
case where we were missing a diagnostic due to an explicit capture,
rdar://85988937.
Non-isolated declarations in general do not require Sendable
diagnostics. However, we do need to make sure that `nonisolated let`
accesses to actor-isolated state are always cross-actor.
Fixes rdar://83371627.
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.
