When checking for the sendability in a call, use the sendability of the
original argument expressions rather than the parameter type, looking
through any implicit conversions that might remove `Sendable`.
Fixes rdar://110763694 / FB12343467.
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.
When a class has an unavailable conformance to a protocol, do not
inherit that unavailable conformance, because it can get in the way of
subclasses defining their own (properly-available) conformance.
Fixes rdar://89992569.
When determining whether a superclass conforms to a particular protocol,
skip unavailable conformances. This way, we don't minimize away a
constraint that might only apply to subclasses of the specified
superclass.
Fixes rdar://91853658.
The three options are now:
* `explicit`: Enforce Sendable constraints where it has been explicitly adopted and perform actor-isolation checking wherever code has adopted concurrency. (This is the default)
* `targeted`: Enforce Sendable constraints and perform actor-isolation checking wherever code has adopted concurrency, including code that has explicitly adopted Sendable.
* `complete`: Enforce Sendable constraints and actor-isolation checking throughout the entire module.
when a variable with type `<<error-type>>` was captured in a
sendable function's environment, we use to emit a diagnostic
about it not being sendable, but it's for a bogus type.
at some point this issue disappeared as the sendable implementation
evolved, but this commit adds regression coverage.
resolves rdar://82452688
Use the explicit check for a Sendable conformance (even an unavailable
one) as the mechanism for determining whether to diagnose a
missing/unavailable Sendable conformance in a particular context.
When in "existing" Swift code that is Swift 5.x and has not adopted
concurrency, allow mismatches in function types that only involve
ABI-neutral concurrency changes (e.g., adding `@Sendable` or removing
a global actor) by downgrading the diagnostic to a warning. This
improves the story for incremental adoption of concurrency in an
existing code base.
As part of this, generalize the facility for downgrading an error to a
warning when performing diagnostics in the constraint solver, using the
new diagnostic behavior limits rather than duplicating diagnostics.
