Merge release/dev17.0 to main #57008
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
The FinalState in the compilation tracker holds onto two compilations: the compilation with generated files (the "real" compilation) and the compilation without generated files, should we need to later re-run generators if any further forking were to happen. When we froze a snapshot with partial semantics, the code was assuming that no further forking would happen, so it incorrectly passed the compilation with generated files into the field that should hold the compilation without generated files; if we later forked, we'd run generators again and that would result in us trying to add generated trees that already existed. The fix is to correctly track both compilations through that path like anything else. To start making that process simpler, I introduce a CompilationPair type that just holds onto both and lets you mutate both at once. There's also an optimization to ensure that if we don't have any generated files we aren't actually forking Compilations twice for no reason, which was a previous guarantee we held. Fixes #56702
We still had a few places where we were decomposing the GeneratorInfo type to pass it into the parameters for FinalizeCompilationAsync; it's easier if we just pass it around directly and process the values in FinalizeCompilationAsync.
This implements a policy change that once we freeze semantics for a document, we won't ever run geneators again, even if we further fork and replace that original document. This implemented by adding another boolean to ur GeneratorInfo: besides having a flag which indicates whether we don't need to rerun generators for this specific state, we also add a flag to say never run even if we do change.
Since we can reuse trees from prior runs, that might hide the fact we ran generators but then reused the prior tree anyways, when we really wanted to ensure generators didn't run at all.
…r-freeze Don't break if we fork a snapshot after freezing partial semantics
ghost
added this to the
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 is an automatically generated pull request from release/dev17.0 into main.
Once all conflicts are resolved and all the tests pass, you are free to merge the pull request. 🐯
Troubleshooting conflicts
Identify authors of changes which introduced merge conflicts
Scroll to the bottom, then for each file containing conflicts copy its path into the following searches:
Usually the most recent change to a file between the two branches is considered to have introduced the conflicts, but sometimes it will be necessary to look for the conflicting lines and check the blame in each branch. Generally the author whose change introduced the conflicts should pull down this PR, fix the conflicts locally, then push up a commit resolving the conflicts.
Resolve merge conflicts using your local repo
Sometimes merge conflicts may be present on GitHub but merging locally will work without conflicts. This is due to differences between the merge algorithm used in local git versus the one used by GitHub.
git fetch --all git checkout -t upstream/merges/release/dev17.0-to-main git reset --hard upstream/main git merge upstream/release/dev17.0 # Fix merge conflicts git commit git push upstream merges/release/dev17.0-to-main --force