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
If root type of a key path has been determined to be a hole there
is no reason to delay the inference decision which should be a
failure because none of the components would be inferrable from
a placeholder root.
Produce a tailored diagnostic that omits a fully unresolved key path
type (`KeyPath<_, _>`) when key path without an explicit root type is
passed as an argument to non-keypath parameter type (i.e. `Int`).
Since key path root is now transitively inferred. Key path type
inference can be delayed until key path is resolved enough to
infer its capability.
This solves multiple problems:
- Inference fully controls what key path type is bound to;
- KeyPath constraint simplification doesn't have to double-check
the capability and attempt to re-bind key path type;
- Custom logic to resolve key path type is no longer necessary;
- Diagnostics are improved because capability and root/value type
mismatch are diagnosed when key path is matched against the
contextual type.
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.
If key path is connected to a disjunction directly or indirectly
(i.e. via ApplicableFunction constraint) do not attempt to bind
it until disjunction is taken, otherwise there is a risk to miss
a valid keypath-to-function conversion.
If there is something wrong with the context, let's assign a default
KeyPath type to the key path literal to avoid propagating placeholder
into the key path inference.
For methods there are two possibilities - force unwrap and
conditional, that's why we need a disjunction with two choices.
This is not the case for key path root type it could only
be force unwrapped.
A key path without an explicit root cannot be unwrapped since the
optionality is inferred from context and we cannot suggest removing
that, adding explicit type is not going to change anything and
`!` and `?` after the leading dot is not supported.
`tryMatchRootAndValueFromType` anchored both root and value match
constraints directly on the key path expression. That is incorrect
because we have special locators for that.
If key path literal is passed as an argument to a function/subscript
application its type cannot be resolved until the overload for the
call is selected, otherwise it could prevent a valid keypath-to-function
conversion in cases were argument ends up being a function type.
If type of the key path expression is convertible to an existential
value with a superclass constraint represented as a known key path
type, we can use it to inform key path inference.
Resolves: rdar://93103421
If all solutions point to the same overload choice that needs
re-labeling it's safe to diagnose it as if there was no ambiguity
because the call site is static.
If underlying type of an optional chain has been marked as a hole,
e.g. due to a reference to an invalid or missing member, let's
propagate that information to object type of an optional that
represents a result of an optional chain.
Resolves: rdar://80941497
It's not permitted to use `PartialKeyPath` type to resolve a key path
expression, because that type is intended to be a type-erased version of
a fully resolved `KeyPath` type.
In situations where contextual type is a partial key path (e.g. parameter
type is a partial key path), let's replace it with a `KeyPath` type that
is a subtype of `PartialKeyPath` and allow value inference to happen.
Resolves: SR-5667
Resolves: rdar://32365183
Restrict filtering in `simplifyAppliedOverloadsImpl` to disable
overload set for operators only, because other calls e.g. regular
functions or subscripts could be filtered on labels and are less
overloaded.
Filtering non-operator calls could also lead to incorrect diagnostics
because first choice could have all sorts of different issues e.g.
incorrect labels and number of parameters.
Resolves: rdar://55369704
If member has been bound before the base and the base was
incorrect at that (e.g. fallback to default `Any` type),
then we need to re-activate all of the constraints
associated with this member reference otherwise some of
the constraints could be left unchecked in inactive state.
This is especially important for key path expressions because
`key path` constraint can't be retired until all components
are simplified.
Resolves: SR-13364
Resolves: rdar://66706980
Resolves: rdar://74711236
* [CSDiagnostics] Adjusting MemberAccessOnOptionalBaseFailure to be able to handle key path component member base types
* [tests] Adding regression tests for SR-5688
* [CSDiagnostics] Adjusting source range to diagnose/insert the fixes in correct location
* [tests] Adjusting regression tests to handle the fixits
* [AST] Creating an helper getSourceRange function for KeyPathExpr::Component
* [ConstraintSystem] Store member base type when recording UnwrapOptionalBase fix
* [AST] Creating a new diagnostic note for removing optional from written type
* [CSDiagnostics] Adjusting logic around MemberAccessOnOptionalBaseFailure to emit the correct diagnostics and fixes
* [tests] Adjusting regression tests to add subscript and key path root cases with respective diagnostics
* [Diagnostics] Adjusting message to mention base type
* [CSDiagnostics] Better naming for method/variable that represents base source range
* [CSDiagnostics] Adjusting to use the stored base member only when member is a key path component.
* [Diagnostics] Adjusting minor typos and code
* [AST] Adjusting keypath root diagnostic note message for use unwrapped type
* [CSDiagnostics] Adjusments in MemberAccessOnOptionalBaseFailure diagnostics as per suggestion
* [tests] Adding more test cases for SR-5688
* [CSDiagnostics] Adjusting fixits for key path root and range for diagnostics
* [CSSimplify] Attempt to diagnose InsertExplicitCall for optional function return types when possible on simplifyOptionalObjectConstraint
* [tests] Adding TODO to improve the diagnostics refering to key path root infered as optional types
* [CSDiagnostics] Adjusting comments
* [CSSimplify] Adjusting logic on simplifyOptionalObjectConstraint to attempt InsertCall fix before remove unwrap
* [CSDiagnostics] Adjust the logic to use resolveType on MemberAccessOnOptionalBaseFailure construction
Instead of requiring sub-classes of `ContextualMismatch` to implement
`diagnoseForAmbiguity` let's implement it directly on `ContextualMismatch`
itself and check whether all of the aggregated fixes have same types on
both sides and if so, diagnose as-if it was a single fix.
We currently leave a key path constraint unsolved
if one of its components hasn't yet had its
overload resolved. However, for e.g a missing
member component, the overload type variable will
be bound to a hole and an overload will never be
resolved.
Tweak the logic to consider the key path constraint
trivially solved if one of its components has been
marked as a hole, which will allow the key path
type itself to be marked as a hole.
Resolves SR-12437 & SR-12823.
Resolves rdar://62201037.
