[ConstraintSystem] Initial rework of key path inference #69405
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
cc @amritpan |
|
@swift-ci please test |
|
@swift-ci please test Linux platform |
1 similar comment
|
@swift-ci please test Linux platform |
This is a very first step in attempt to move some of the logic from `simplifyKeyPathConstraint` to the inference. This type is going to be used as an anchor to trigger capability inference.
If there are no contextual types available but capability of key path could be inferred, let's turn default into a real binding.
…th type is bound Let the inference drive key path literal resolution, this fixes a problem where key path is bound too eagerly.
Detect that diagnose key path literals that do not have any components.
Since key path type is always bound by inference before the constraint could be simplified, there is no need to search for a contextual type or try to bind key path type if there are errors in the path.
Make sure that contextual mismatch uses a correct locator when the issue is with key path value type instead of the key path type.
…ed root types 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.
…her key path is invalid This flag makes it easier to determine what binding to produce from the default. In cases where some of the member references are invalid it's better to produce a placeholder for a key path type instead of letting the solver to attempt to fix more contextual problems for a broken key path.
Move some of the checks from the constraint simplification into `inferKeyPathLiteralCapability` and start using it for both inference and constraint simplification.
…tchRootAndValueFromType`
xedin
force-pushed
the
rework-keypath-type-inference
branch
from
8a460aa to
7363812
Compare
|
@swift-ci please test |
|
@swift-ci please test source compatibility |
1 similar comment
|
@swift-ci please test source compatibility |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Depends on #69292
Setup a fallback type for a key path that is going to be used as a base for capability inference.
If key path has no direct contextual bindings attempt to infer its capabilities and form a binding
based on a previously established fallback type (default capability is ReadOnly).
Delay
KeyPathconstraint simplification until key path type has been bound.This means that the inference now drives key path simplification and problems
with eager key path binding are resolved (because type variables are already
delayed if they are connected to an
ApplicableFunctionorDisjunctionconstraint).Next steps:
capabilities. This means that we would no longer need to:
(i.e. when contextual type is read-only but key path itself is writable)