-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merge release/dev16.10 to main #53033
Merged
Merged
Conversation
This file contains 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
Cancel all current work with highlight refs when changes come in
In 63a1ad6 we made some performance optimizations where we would try to reuse compilations better. The core idea was if a change to a file happens, we have to update the compilation that doesn't contain source generated files so we can re-run generators; if the generated output was the same then we should also do the same updates to the compilation that _has_ source generators so we can better use compiler caches. The one case that wasn't handled well was if the compilation with and without generated output was actually the same: if a generator was added that isn't producing documents, then those compilations can be the same instance, but we were applying the transformations twice as if they were different. This fired an assert elsewhere in the CompilationTracker that when we're storing compilations away at the very end we shouldn't have two separate but semantically identical compilations if there are no actual generated files anywhere. The fix taken here is to adjust our logic where we update compilations for changes to regular files: there we were updating both compilations at once. If the compilations are identical, we just null out the "withGenerators" since we won't need to update that as well. That way we're only updating one copy, which will be the one passed to generators again. And if no generated output is still produced, that'll be the single compilation again stored in the FinalState.
Optimize the case when we have a generator not producing output
Move to Ubuntu 18.04 queue
…actory-implementation Do not show UI if no managed projects are loaded
Make CodeAction.CustomTags internal
ghost
approved these changes
Apr 29, 2021
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Auto-approval
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/dev16.10 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 merges/release/dev16.10-to-main git reset --hard upstream/main git merge upstream/release/dev16.10 # Fix merge conflicts git commit git push upstream merges/release/dev16.10-to-main --force