Skip to content

Merge main to main-vs-deps#52005

Merged
362 commits merged intomain-vs-depsfrom
merges/main-to-main-vs-deps
Mar 20, 2021
Merged

Merge main to main-vs-deps#52005
362 commits merged intomain-vs-depsfrom
merges/main-to-main-vs-deps

Conversation

@dotnet-bot
Copy link
Collaborator

This is an automatically generated pull request from main into main-vs-deps.

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/main-to-main-vs-deps
git reset --hard upstream/main-vs-deps
git merge upstream/main
# Fix merge conflicts
git commit
git push upstream merges/main-to-main-vs-deps --force

…sAndPropertiesAndBeforeUnimportedItems from Function to Sub
MaStr11 and others added 18 commits March 18, 2021 22:05
Update RemoveUnnecessaryCastTests.cs
…eUsingAsLiteral

Ensure resource strings will be valid in string literals
…able

We were handling target-typed conditional and switch expressions wrong in a few cases, which caused a series of issues:

1. Lambdas underneath these contexts were never visited in nullable, so warnings in their bodies weren't reported.
2. Target-typed conditionals contributed to nullable inference of the thing they were getting their target-type from in the first place.

To fix this, I've made a couple of changes. First, we add a discrete BoundConversion node for the target-typed conditional conversion. This ensures that the standard "remove conversion, visit operand, redo conversion" practice we have throughout the nullable walker handles these constructs correctly. I also split up the conversion steps for these constructs: if the construct was target typed, we now save the states for each branch at the end of their respective VisitX methods, and then when we have a target-type with nullability in VisitConversion, we pull that info out and visit the nested contexts correctly. As part of this, I fixed a couple of other bugs:

1. VisitSwitchExpression was needlessly calling VisitConversion multiple times. This caused some warnings to be double-reported, which it now only reports once.
2. We were missing IConversionOperation nodes that should have been in the IOperation tree.
3. The behaviors for GetTypeInfo and GetConversion didn't match our usual handling of explicit vs implicit conversions.

Fixes #51403. Fixes #49735.
Fix additional cancellation case for GetAssetsAsync
Intellisense for cast, indexers and operators
Add SolutionFilter support to MSBuildWorkspace
Copy link

@ghost ghost left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Auto-approval

@ghost ghost merged commit eaa0412 into main-vs-deps Mar 20, 2021
@ghost ghost deleted the merges/main-to-main-vs-deps branch March 20, 2021 23:43
@ghost ghost added this to the Next milestone Mar 20, 2021
@allisonchou allisonchou modified the milestones: Next, 16.10.P2 Mar 29, 2021
This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

10 participants