We were doing the conformance check through a lower-level interface that
didn't deal with the unavailable Sendable synthesis.
Fixes a spurious diagnostic reported via rdar://85894346.
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.
This attribute creates an unavailable extension with a `Sendable` conformance so that the type is explicity marked as not being `Sendable`.
We also fully suppress diagnostics about unavailable Sendable conformances in Swift 5 mode code. (This is not fully developed yet—it should return to being a warning in concurrent contexts.)
The behavior when a @_nonSendable and a Sendable conformance are both on the same type is also not right yet.
When a type has provided an unavailable `Sendable` conformance, don't
check its instance storage for `Sendable`. Additionally, teach
`-require-explicit-sendable` to avoid trying to add a `Sendable`
conformance when some of the instance storage relies on unavailable
`Sendable` conformances.
When proposing to annotate a public type as `Sendable` due to the
`-require-explicit-sendable` command-line parameter, suggest a
conditional conformance when it can be determined that a generic type
would be `Sendable` when certain type parameters are `Sendable`.
For example, given this type:
public struct DictionaryHolder<T: Hashable, U, V> {
var member: [T: (U, V?)]
}
We will now produce a Fix-It that suggests that one add:
extension DictionaryHolder: Sendable
where T: Sendable, U: Sendable, V: Sendable { }
Becca noticed that one can already write an unavailable `Sendable`
conformance in language:
@available(*, unavailable)
extension MyType: Sendable { ... }
Add tests to verify that this suppresses the "missing Sendable
annotation" warning (it does) and suggest this spelling in a Fix-It to
help users find it.
