[ConstraintSystem] Record originator constraint for each type variable binding #28752
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
Unify all of the fields of `PotentialBinding` which have to do with location information into a single field with is either a constraint (for regular bindings) or constraint locator (for "holes"). This helps to reduce the amount of space used by `PotentialBinding` as well as propagate more contextual information when binding gets attempted.
…iness Solver needs to attempt both escaping and non-escaping variants to determine correct error location.
…match Sometimes diagnostic needs both sides of the conversion e.g. when there is an attempt to bind generic argument to non-escaping type.
…ostic This is useful in some situations where access to type variable(s) helps to diagnose the problem properly e.g. if it's a conversion to generic parameter.
This gives diagnostic access to both sides of a conversion/binding which makes it easier to diagnose errors associated with generic parameters.
Since `binding` has all of the required information now it's possible to use its `locator` as a source of type variable assignment (`Bind` constraint) in `TypeVariableBinding::attempt` which helps to improve diagnostics.
xedin
force-pushed
the
simplify-potential-binding
branch
from
01bcce9 to
87beea3
Compare
|
@swift-ci please smoke test |
| @@ -1548,8 +1548,8 @@ ConstraintSystem::matchFunctionTypes(FunctionType *func1, FunctionType *func2, | |||
| if (!shouldAttemptFixes()) | |||
| return getTypeMatchFailure(locator); | |||
|
|
|||
| auto *fix = MarkExplicitlyEscaping::create( | |||
| *this, getConstraintLocator(locator), func2); | |||
| auto *fix = MarkExplicitlyEscaping::create(*this, func1, func2, | |||
There was a problem hiding this comment.
Nice!
That's exactly the diagnostic which was failing when I try to use the source locator as the binding locator, I definitely was missing something 😅
There was a single place where it was used to determine whether a binding comes from an argument conversion constraint. Since constraint locator is part of the binding now it's possible to use it instead and remove unused accessor.
|
@swift-ci please smoke test |
hborla
approved these changes
Dec 13, 2019
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.
This helps with a couple of things:
Simplify
PotentialBindinginterface and its memory footprint;Provide more contextual information when a binding gets
attempted because it's possible to use locator of the binding
as a source of assignment.