Currently `getPotentialBindingsForRelationalConstraint` doesn't
respect the fact that type of key path expression has to be a
form of `KeyPath`, instead it could eagerly try to bind it to
`Any` or other contextual type if it's only available
information.
This patch aims to fix this situation by filtering potential
bindings available for type variable representing type of
the key path expression.
Resolves: SR-10467
Since there is a way to mutate through use of writable keypath
diagnostics have to be adjusted to point to the members found
via keypath member lookup instead to using catch-all
"immutable base" diagnostic.
Using an anonymous union in KeyPathPatternComponent instead of the weird void * in SetterAndIdKind
Added TupleElement kind to KeyPathComponentKindEncoding
Written basic SIL keypath serialization tests
Deleted or edited some old Swift-level tuple key path tests
Extend existing `RequirementFailure` functionality to support
conditional requirement failures. Such fixes are introduced
only if the parent type requirement has been matched successfully.
Resolves: rdar://problem/47871590
This makes diagnostics more verbose and accurate, because
it's possible to distinguish how many parameters there are
based on the message itself.
Also there are multiple diagnostic messages in a format of
`<descriptive-kind> <decl-name> ...` that get printed as
e.g. `subscript 'subscript'` if empty labels are omitted.
`\.self` is the final chosen syntax. Implement support for this syntax, and remove the stopgap builtin and `WritableKeyPath._identity` property that were in place before.
If generic parameter associated with missing conformance comes
from different context diagnose the problem as "referencing" a
specific declaration from affected type.
Instead of simply pointing out which type had conformance failures,
let's use affected declaration instead, which makes diagnostics much
richer e.g.
```
'List<[S], S.Id>' requires that 'S.Id' conform to 'Hashable'
```
versus
```
initializer 'init(_🆔)' requires that 'E' conform to 'Hashable' [with 'E' = 'S.Id']
```
Since latter message uses information about declaration, it can also
point to it in the source. That makes is much easier to understand when
problem is related to overloaded (function) declarations.
We inadvertantly allowed this in the past, so continue to do so when
compiling in Swift 3/4 mode to avoid suddenly breaking existing code.
The diagnostic here is pretty bad, and I've opened issues for that as
well as providing some kind of deprecation warning for this so that
even under Swift 3/4 mode we alert users that this is unsupported.
rdar://problem/39802797
`AbstractStorageDecl::isSettable` by itself doesn't account for access control, so we need to check `isSetterAccessibleFrom` as well. Furthermore, key paths should not get the special context-sensitive privileges direct accesses do, such as initializers being able to assign into `let` properties. Fix the type checking logic here to only create a statically writable KeyPath value when the referenced declaration has a setter visible independent of current context. Fixes SR-6667 | rdar://problem/36257266.
When testing KeyPathApplication constraints, we would keep going after rejecting a concrete KeyPath application by trying PartialKeyPath and AnyKeyPath, even though that's not what we want, since any key path application expression can type check with an AnyKeyPath. We would then miscompile by building the AST such that we applied the mismatched key path expression directly to the base. We also didn't handle expressions where the base was a subtype of the key path's base type correctly—the conversion means the base can't be written through in this situation, and we hardcoded the concrete-to-existential case instead of handling general conversions. Fix these problems, and add an AST verifier for KeyPathApplicationExprs to help catch problems in the future. Fixes SR-6300 | rdar://problem/35368903.
We can wind up in a situation where the base of a keypath
application is concrete but is being applied to a keypath
with an existential source type. Coerce the base to the
intended type if necessary when building the final subscript
expression.
Resolves SR-5878.
