Closures generally only inherit actor instance isolation if they directly
capture state from the actor instance. In this case, for some reason that is not
true, so we hit an assert that assumes that we will only see a global actor
isolated isolation.
Region Isolation should be able to handle code even if the closure isolation
invariant is violated by the frontend. So to do this, I am introducing a new
singleton actor instance to represent the isolation of a defer or closure
created in an actor instance isolated method. The reason why I am using a
singleton is that closures and defer are not methods so we do not actually know
which parameter is 'self' since it isn't in the abi. But we still need some
value to represent the captured values as belonging to. To square this circle, I
just did what we have done in a similar situation where we did not have a value:
(ActorAccessorInit). In that case, we just use a sentinel to represent the
instance (NOTE: This is represented just via a kind so ActorInstances that are
operator== equal will not &value equal since we are just using a kind).
Sendable conformances for source compatibility.
If conformance lookup always prefers the conformance from the defining module,
libraries introducing unavailable Sendable conformances can break source in
clients that declare retroactive Sendable conformances. Instead, still prefer
the available conformance, and always diagnose the client conformance as
redundant (as a warning). Then, when the retroactive conformance is removed,
the errors will surface, so the programmer has to take explicit action to
experience the source break.
defining module, and diagnose redundant Sendable conformances.
We still allow re-stating inherited unchecked Sendable conformances in
subclasses because inherited Sendable conformances are surprising when
they opt out of static checking. Otherwise, warning on redundant Sendable
conformances nudges programmers toward cleaning up unnecessary retroactive
Sendable conformances over time as libraries incrementally add the
conformances directly.
When SE-0412 (strict concurrency for global variables) is enabled, each
global or static mutable variable will be diagnosed if it isn't
explicitly on a global actor or `nonisolated(unsafe)`.
Suppress diagnostics for references to such global variables when they
are in the same module as the declaration of the global variable
itself. While these diagnostics are technically correct, they are not
strictly necessary since we've already diagnosed the global variable
itself (with more actionable advice), and they tend to pile on the
developer in a manner that is not helpful.
When diagnosing a concurrency-unsafe global or static variable, provide
Fix-Its with specific guidance and advice. This is intended to aid the
workflow for folks enabling strict concurrency checking or Swift 6.
There are up to three Fix-Its attached to a diagnostic about
concurrency-unsafe global/static variables:
* convert 'global' to a 'let' constant to make the shared state
immutable, which replaces `var` with `let`
* restrict 'global' to the main actor if it will only be accessed from the
main thread, which adds `@MainActor`
* unsafely mark %0 as concurrency-safe if all accesses are protected
by an external synchronization mechanism, which adds `nonisolated(unsafe)`
I fretted over two things before deciding on this path:
1. For the second note, the reality is that any global actor will
suffice, but `@MainActor` is orders of magnitude more common than any
other global actor, so "common case convenience" wins over "precise
but less useful.
2. For the third note, `nonisolated(unsafe)` should only be used
sparingly, and surfacing it via Fix-It could cause overuse. However,
developers need to know about it, and this is how we do that. It comes
last in the list of notes (after the better options) and says "unsafe"
in not one but two places.
When a retroactive conformance to a protocol that inherits from `Sendable`
introduces an implicit `Sendable` conformance, allow `@preconcurrency`
to suppress the diagnostic about the `Sendable` conformance being
introduced outside of the original source file.
Fixes rdar://125080066.
The diagnostic for non-Sendable globa/static `let` properties was checking
for a Sendable conformance without considering `@preconcurrency`. Emit
this diagnostic via a `@preconcurrency`-sensitive path.
Fixes rdar://121889248.
This translates the rules for @preconcurrency import from SE-0337 into the
region isolation world. Specifically if a module is compiled without strict
concurrency checking and imported with @preconcurrency:
1. All types from that module that are implicitly non-Sendable have diagnostics
suppressed in swift 5 and swift 6.
2. All types from that module that are explicitly non-Sendable emit warnings in
both swift 5 and swift 6.
rdar://126804052
I fixed a bunch of small issues around here that resulted in a bunch of radars
being fixed. Specifically:
1. I made it so that we treat function_refs that are from an actor isolated
function as actor isolated instead of sendable.
2. I made it so that autoclosures which return global actor isolated functions
are treated as producing a global actor isolated function.
3. I made it so that we properly handle SILGen code patterns produced by
Sendable GlobalActor isolated things.
rdar://125452372
rdar://121954871
rdar://121955895
rdar://122692698
This involved fixing a few different bugs.
1. We were just performing dataflow by setting that only the initial block needs
to be updated. This means that if there isn’t anything in the initial dataflow
block, we won’t visit any successor blocks. Instead the correct thing to do here
is to visit all blocks in the initial round.
2. I also needed to fix a separate issue where we were updating our union-find
data structure incorrectly as found by an assert on transfernonsendable.swift
that was triggered once I fixed 1. Put simply, we needed to set a new max label
+ 1 when our new max element is less than or equal to the old max label + 1…
before we just did less than so if we had a new max element that is the same as
our fresh label, we wouldn’t increment the fresh label.
rdar://119584497
The change in #59479 inadvertently fixed another bug in selector conflict checking: Swift did not notice when an ObjC header declared an async-imported method, but a Swift extension to the same class added another method with the same selector. Unfortunately, fixing this bug was source-breaking, and it also caused Swift to diagnose spurious conflicts between the various names that a single ObjC method might be imported with. Soften the error to a warning in Swift 5 mode and suppress the spurious diagnostics.
Fixes rdar://95887113.
When the conformance checker and override checker detect a difference in a function type’s @Sendable attribute that varies in an illegal way, they now check if the protocol/base class was imported with an @preconcurrency import, and either limit the diagnostic or suggest adding @preconcurrency to the import as appropriate.
Completes rdar://91109455.
If a type is explicitly non-Sendable, we don’t want to recommend softening errors with `@preconcurrency import` (even thought that would still work), because these probably represent *real* errors that you ought to fix. And at the extreme end of this, if a module is built with `-warn-concurrency` or `-swift-version 6`, *all* of its types should be treated as though they have explicit sendability, since we assume the entire module has been audited.
(Eventually, we plan to do this at module build time by actually serializing out unavailable conformances rather than by looking at the settings used to build the module, but we aren’t there quite yet.)
Implement this and test it by checking that the preconcurrency sendable tests never recommend adding `@preconcurrency` to an import of `StrictModule`, even when we do the same illegal things with it that cause that remark to be printed for `NonStrictModule`.
When compiling with Swift 6 mode, but using a serialized module
that is using Swift 5 that contains a struct with global-actor
isolation on its stored property, we should not emit an error
for that stored property. Only a warning was emitted when compiling
that module, but the checks here were treating that module as being
type-checked again under a Swift 6 world.
In Swift 5 mode, I only warned about the global-actor attribute
becoming unnecessary in the future, yet I was still returning
None for the global-actor attribute checking request. This led
to the attribute remaining unidentified, but also not removed.
During module serialization, this problem was manifesting as
emitting a typeless attribute, which when deserialized would
trigger a segfault.
This patch adds a bunch of tests to verify the behaviour of the
@_unavailableFromAsync attribute.
The attribute is only allowed on functions, so we verify that an error
is emitted when it is applied to structs, extensions, classes, and
actors. The attribute may be applied to constructors to disallow
construction in an async context, but cannot be applied to destructors
since a destructor must be callable from anywhere. Additionally, the
attribute cannot be applied to asynchronous functions since an async
function _must_ be called from an async context.
Specific checks include
- Errors are emitted in an async context (global function, e.g.)
- Errors are emitted when the async context is nested in a sync context
- Errors are not emitted from a sync context nested in an async context
This patch also includes verification that the attribute is propagated
across module boundaries and is be imported from ObjC functions.
Lastly, this patch adds the IDE completion testing to verify that the
attribute is considered.
When trying to access a let-bound property of an actor across
a moudule boundary, the operation should be treated as async.
But, upon reaching SILGen, the compiler would crash when trying
to emit the needed hop, because the base of the element reference
was missing. This commit fixes that and adds regression coverage.
resolves rdar://81812013
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.
Implement the remainder of the amendment to SE-0306 "Actors" that
considers any reference to an actor-isolated `let` from within a
different module like a (mutable) property reference. If such
references are from outside the actor, it will be a cross-actor
reference at will be implicitly `async`.
The `Task` type has oscillated somewhat from being purely a namespace,
to having instances that are used (albeit rarely), back to purely
being a namespace that isn't used for all that many names. Many of the
names that used to be on Task have already been moved out, e.g., for
creating new detached tasks, creating new task groups, adding
cancellation handlers, etc.
Collapse `Task.Handle<Success, Failure>` into `Task<Success, Failure>`.
`Task.Handle` is the type that is most frequently referenced in the
concurrency library, so giving it the short name `Task` is most
appropriate. Replace the top-level async/detach functions with a
`Task` initializer and `Task.detached`, respectively.
The `Task` type can still act as a namespace for static operations
such as, e.g., `Task.isCancelled`. Do this with an extension of the
form:
extension Task where Success == Never, Failure == Never { ... }
We've been accruing a number of compatibility shims. Move them all
into their own source file, deprecate them, and make them
always-emit-into-client so they don't have any ABI impact.
Asking for Sendable conformances on this path is going to lead to
a traversal of the stored properties of the type. If there is an
interface type computation ongoing, as is very likely the case, this
traversal can wind up causing a cycle when it forces the interface type
of a member once again.
Request only the non-structural conformances to break the cycle.
rdar://77189542
Previously, the method table would contain duplicate copies due to the
ProtocolDecl carrying a completionHandler-based version of the method,
as well as the async version of the method.
Fixes rdar://76192003.
