When diagnosing a case where an actor-isolated witness cannot satisfy
a non-isolated requirement, also suggest that the conformance could be
annotated with `@preconcurrency`.
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.
Instead of looking at captures, which wasn't sound with
recursive local functions; we would look at the captures of
the function currently being type checked, which are not
available yet.
property for IsolatedDefaultValues.
For property wrappers and init accesors, skip property initializers that are
subsumed, e.g. by an init accessor or a backing property wrapper initializer,
and always consider the subsuming initializer to determine whether compiler
synthesized initializers should have `nonisolated` applied.
This change also lessens the source break of SE-0411 by still emitting
member initializers in implicit constructors when the initializer violates
actor isolation to preserve the behavior of existing code when concurrency
diagnostics are downgraded to warnings in Swift 5 mode.
Remarks are intended to be enabled via eg. `-R...`, where as
`(add|remove)_predates_concurrency_import` is a diagnostic that's always
output without any `-R` flag. Move it to a warning instead.
Resolves rdar://114207080.
actor isolation.
Adding global actor isolation via subclassing admits data races because
actor-isolated types are Sendable while nonisolated classes are not (unless
otherwise annotated), so this allowed bypassing Sendable checking.
This means that:
1. In test cases where minimal is the default (swift 5 without
-warn-concurrency), I added RUN lines for targeted, complete, and complete +
sns.
2. In test cases where complete is the default (swift 6, -warn-concurrency,
specified complete with -strict-concurrency), I added a send non-sendable run
line.
In each of these cases, I added additional expected-* lines as appropriate so
the tests can compile in each mode successfully.
Isolation checking for calls had two separate implementation places:
one that looked at the declaration being called (for member
declarations) and one that worked on the actual call expression. Unify
on the latter implementation, which is more general and has access to
the specific call arguments. Improve diagnostics here somewher so we
don't regress in that area.
This refactoring shouldn't change the actual semantics, but it makes
upcoming semantic changes easier.
It's ok to drop the global-actor qualifier `@G` from a function's type if:
- the cast is happening in a context isolated to global-actor `G`
- the function value will not be `@Sendable`
- the function value is not `async`
It's primarily safe to drop the attribute because we're already in the
same isolation domain. So it's OK to simply drop the global-actor
if we prevent the value from later leaving that isolation domain.
This means we no longer need to warn about code like this:
```
@MainActor func doIt(_ x: [Int], _ f: @MainActor (Int) -> ()) {
x.forEach(f)
// warning: converting function value of type '@MainActor (Int) -> ()' to '(Int) throws -> Void' loses global actor 'MainActor'
}
```
NOTE: this implementation is a bit gross in that the constraint solver
might emit false warnings about casts it introduced that are actually
safe. This is mainly because closure isolation is only fully determined
after constraint solving. See the FIXME's for more details.
resolves rdar://94462333
Instead of the `warning` Boolean threaded through the solver's
diagnostics, thread `DiagnosticBehavior` to be used as the behavior
limit. Use this for concurrency checking (specifically dropped
`@Sendable` and dropped global actors) so the solver gets more control
over these diagnostics.
This change restores the diagnostics to a usable state after the prior
change, which introduced extra noise. The only change from existing
beavior is that dropping a global actor from a function type is now
always a warning in Swift < 6. This is partly intentional, because
there are some places where dropping the global actor is well-formed.
