[ConstraintSystem] A few improvements to key path handling and diagnostics #69031
Conversation
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.
…ing constraints `tryMatchRootAndValueFromType` anchored both root and value match constraints directly on the key path expression. That is incorrect because we have special locators for that.
…xplicit type 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.
…h type Such types are not going to be applied by `ConstraintSystem::resolveClosure` anyway and they impede diagnostics by forcing the solver to produce mutliple equal solutions.
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 placeholder 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.
|
@swift-ci please test |
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.
|
@swift-ci please test |
| auto resolvedKPTy = | ||
| BoundGenericType::get(kpDecl, nullptr, {rootTy, valueTy}); | ||
| return matchTypes(resolvedKPTy, keyPathTy, ConstraintKind::Bind, | ||
| subflags, loc); |
There was a problem hiding this comment.
In the little digging I did on this issue, it struck me that it seems like in this path we're basically using the simplification step to infer a KeyPath-type binding for the literal (by simplifying to a Bind constraint). Do you know why we wouldn't want to use the usual PotentialBindings::infer machinery to do that? It seems like we could then use BindingSet::favoredOverDisjunction to ensure we don't attempt the binding until we've resolved disjunctions rather than searching for the constraints here?
There was a problem hiding this comment.
We cannot use binding inference for this because constraint gets re-activated when adjacent types are bound.
There was a problem hiding this comment.
I put a branch into resolveKeyPath to handle contextual placeholder but here I think we actually want to have it bound to propagate “unknown type” information out.
| return match->getKind() == | ||
| ConstraintKind::ApplicableFunction || | ||
| match->getKind() == ConstraintKind::Disjunction; |
There was a problem hiding this comment.
If we're just looking for function/disjunction constraints, how does this handle the let fn = \User.email as (User) -> String?
There was a problem hiding this comment.
Coercions form disjunctions
|
@swift-ci please test windows platform |
|
@swift-ci please test Windows platform |
|
@swift-ci please test source compatibility |
Resolves: rdar://116376651
Resolves: #55436