[ConstraintSystem] Introduce LValueObject constraint to replace direct l-value assignments
#76174
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
This aims to help with cases like `_ = { x in x = 0 }` or `.test = 42`
which are currently supported because the member is eagerly bound to
an `@lvalue $T` during constraint generation.
|
@swift-ci please test |
|
@swift-ci please test source compatibility |
hamishknight
approved these changes
Aug 30, 2024
| return formUnsolved(); | ||
|
|
||
| // TODO: This operation deserves its own locator just like OptionalObject. | ||
| addConstraint(ConstraintKind::Equal, |
There was a problem hiding this comment.
Out of curiosity, does Bind not work here? I would expect that we shouldn't end up with nested lvalues or anything
There was a problem hiding this comment.
I think the Bind would work here the same way, I just prefer Equal in this case since the type could be bound from context as well which really means that it's an equality operation more than a Bind.
…laceholder Placeholders propagate but we still can allow contextual inference, to facilitate that the solver should consider `l-value object` constraint to be solved and allow placeholders on "object" type.
…text Re-implements swiftlang#76115 in a simpler fashion now that we don't have to eagerly binding destination type on l-value.
…mber settability Increases the default score of the `treat r-value as l-value` and decrease the impact if the immediate member is settable because that means that the problem is somewhere in the "base".
xedin
force-pushed
the
remodel-constraint-generation-for-assignment
branch
from
168c008 to
dab01bc
Compare
|
@swift-ci please test |
|
@swift-ci please test source compatibility |
1 similar comment
|
@swift-ci please test source compatibility |
|
@swift-ci please test |
|
@swift-ci please test macOS platform |
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.
Instead having to eagerly bind type variables to l-value types
like it currently happens during constraint generation for assignment
expressions, let's use new
LValueObjectconstraint (similar toOptionalObjectconstraint) to set "object" type once l-value getsresolved, this allows the solver to infer types and/or resolve overloads
during solving and detect failures related to l-value in one spot.
This makes mismatches easier to diagnose during solving and allows
to simplify some of the logic in constraint generator, inference, and
disjunction favoring.