This matches send non sendable but importantly also makes it clear that we are
talking about something that doesn't conform to the Sendable protocol which is
capitalized.
rdar://151802975
Find all the usages of `--enable-experimental-feature` or
`--enable-upcoming-feature` in the tests and replace some of the
`REQUIRES: asserts` to use `REQUIRES: swift-feature-Foo` instead, which
should correctly apply to depending on the asserts/noasserts mode of the
toolchain for each feature.
Remove some comments that talked about enabling asserts since they don't
apply anymore (but I might had miss some).
All this was done with an automated script, so some formatting weirdness
might happen, but I hope I fixed most of those.
There might be some tests that were `REQUIRES: asserts` that might run
in `noasserts` toolchains now. This will normally be because their
feature went from experimental to upcoming/base and the tests were not
updated.
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.
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.
