Remove keypath subtype asserts; always use cached root type
Add tests for keypaths converted to funcs with inout param
Add unit test for overload selection
Covariant conversions between explicit and contextual/inferred root
types of a key path are simulated through a subtype constraint which
has to be attached to a `KeyPathRoot` element.
`tryMatchRootAndValueFromType` anchored both root and value match
constraints directly on the key path expression. That is incorrect
because we have special locators for that.
We used to represent the interface type of variadic parameters directly
with ArraySliceType. This was awfully convenient for the constraint
solver since it could just canonicalize and open [T] to Array<$T>
wherever it saw a variadic parameter. However, this both destroys the
sugaring of T... and locks the representation to Array<T>. In the
interest of generalizing this in the future, introduce
VariadicSequenceType. For now, it canonicalizes to Array<T> just like
the old representation. But, as you can guess, this is a new staging
point for teaching the solver how to munge variadic generic type bindings.
rdar://81628287
Previously we were using `getPlainType` to match
the parameter type against the key path's base
type. This gave us the external parameter type,
which would be the element type for a variadic
parameter. However the code we generate expects
the internal parameter type, which is provided by
`getParameterType`.
Resolves rdar://problem/59445486.
If there was a mismatch between last component type and contextual
key path result type, let's try to re-match the types with all optionals
stripped off. In cases where the problem is optionality difference
e.g. `[Int] vs. [Int]?` that propagates contextual information to
the last component which facilitates better diagnostics.
Resolves: rdar://problem/57843297
In some situations where both the KeyPath and closure solutions for an expression with a keypath literal were valid, the type checker could not choose between them and Swift would emit an “ambiguous use” error. This change increase the typechecking score of the closure solution so that the typechecker will favor the KeyPath solution, preserving source compatibility for existing APIs.
Fixes rdar://problem/56131416.
We incorrectly allowed some keypaths to be inferred as writable
keypaths in Swift 3/4 modes. This no longer happens when
-swift-version 5 is specified.
This warning is a limited attempt at providing some advanced notice of
code that will break, only in the cases where the keypath is a direct
argument to a keypath subscript write.
Fixes: rdar://problem/40068274
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
