This is an attempt to solving
https://github.com/swiftlang/swift/issues/72199.
As I've already lined out in the issue, this seems to be a two-fold
problem.
The first one was a rather easy fix, as I've seen similar approaches in
different parts of the codebase. It is pretty much just un-currying the
generic function.
The second problem was, that `DependentMemberType`s were counted towards
the generic-parameter-should-only-be-mentioned-once-limit even though
you cannot infer the generic type from the dependent member type.
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 {
...
}
}
```
