Unify ConstraintGraph change tracking with SavedTypeVariableBindings #76759
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 messes up the bookkeeping for the trail.
slavapestov
requested review from
hborla,
xedin,
AnthonyLatsis,
jckarter,
xymus,
eeckstein and
rjmccall
as code owners
slavapestov
force-pushed
the
cstrail-part-0
branch
from
e9dd48b to
cbaccc8
Compare
|
@swift-ci Please smoke test |
|
@swift-ci Please test source compatibility |
xedin
approved these changes
Sep 27, 2024
| } Update; | ||
| }; | ||
|
|
||
| Change() : Kind(ChangeKind::AddedTypeVariable), TypeVar(nullptr) { } |
There was a problem hiding this comment.
It's needed because eg this calls the default constructor and it won't synthesize one for us because of the unions:
SolverTrail::Change
SolverTrail::Change::addedConstraint(Constraint *constraint) {
Change result;
result.Kind = ChangeKind::AddedConstraint;
result.TheConstraint = constraint;
return result;
}
If there's another way to initialize this without the default constructor I can refactor it later, because I'll be adding lots more Change kinds soon. :)
There was a problem hiding this comment.
We have a similar pattern in SyntacticElementTarget, we just need a fee constructors. No need to change anything in this PR if you are going to follow up anyway!
Previously, retractFromInference() was the last step in unbindTypeVariable(). This doesn't really make sense, because bindTypeVariable() doesn't call introduceToInference(); its two callers do it later. Start untangling this by splitting off introduceToInference() into its own Change, but for now, record this change at the incorrect place to maintain the same behavior as before.
slavapestov
force-pushed
the
cstrail-part-0
branch
from
cbaccc8 to
4548880
Compare
|
@swift-ci Please smoke test |
|
@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.
I'd like to get rid of all the state that's inside SolverScope today, and instead record a trail of changes to individual data structures. This is a preliminary PR which moves the ConstraintGraph change tracking into a new
CSTrail.cpp, which defines aSolverTrail. I also refactored the existing logic for saving and restoring the fixed types of type variables to useSolverTrail.For now, there's a hack in there to preserve the previous behavior where type variable bindings are restored before all constraint graph changes. Once I untangle some other issues I will streamline this. Next steps after that are converting all other state tracking to use the new mechanism, which will hopefully reduce memory usage and improve performance.