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.
Reverts code chagnes introduced by 5626881da1 but leaves (modified) test-cases
This approach regressed existing ternary expressions that join to `any Sendable`
and one branch is inferred from the ternary type variable.
A sendable type can be a subtype of a non-Sendable type, i.e.
`any X & Sendable` vs. `X` where `X` is a class. The solver
adjusts `MissingSynthesizableConformance` to indicate that
one of the types is missing `Sendable` and that needs to be
recognized by `TypeChecker::isSubtypeOf`.
- Drop `mayHaveSuperclass` because it's too restrictive.
- Add logic to get superclass of existential and re-create
existential type with all of the protocol requirements.
If the underlying key path is not Sendable, the compiler generated
closure that captures the key path expression (as `{ [$kp$ = ...] in $0[keyPath: $kp$] }`)
cannot be marked as Sendable either.
Allow to compose key path type with a protocol as a way to express
additional requirements on the parameter. For example:
```
struct Test<R> {
subscript<V>(dynamicMember member: KeyPath<R, V> & Sendable) -> V {
...
}
}
```
