These are tests that fail in the next commit without this flag. This
does not add -verify-ignore-unrelated to all tests with -verify, only
the ones that would fail without it. This is NFC since this flag is
currently a no-op.
If key path literal is converted to a read-only type, let's not
use maximum mutability to avoid unnecessary conversions. This is
also important because accessor references are availability checked
and we need to avoid referencing something that is not actually
going to be used.
There are some edge-cases in this approach which would still
produce a conversions, i.e.:
```
struct S {
var a: Int
let b: Int
}
func test<T>(_: T, _: T) {}
test(\S.a, \S.b)
```
Here `\S.a` is going to be converted to `KeyPath<S, Int>`. Availability
checker would still have to recognize situations like that and skip
checking setters if they are not used.
This is a diagnostic that is only really emitted as a fallback when
the constraint system isn't able to better diagnose the expression.
It's not particulary helpful for the user, and can be often be
misleading since the underlying issue might not actually be an
ambiguity, and the user may well already have a type annotation. Let's
instead just emit the fallback diagnostic that we emit in all other
cases, asking the user to file a bug.
Previously dynamic member subscript wasn't allowed to use `& Sendable`,
since this restriction was lifted the argument cannot simply assume
the parameter type any longer, the key path captures have to be checked
to determine whether it could be marked as Sendable or not.
Resolves: https://github.com/swiftlang/swift/issues/77105
Resolves: rdar://138227393
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 {
...
}
}
```
