Skip to content

Conversation

@dotnet-bot
Copy link
Collaborator

This is an automatically generated pull request from main into features/rename_ui_rework.

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

fayrose and others added 30 commits May 30, 2019 13:31
…o merges/master-to-features/param-nullchecking
…-nullchecking

Merge master to features/param-nullchecking
…-nullchecking

Merge master to features/param-nullchecking
…o merges/master-to-features/param-nullchecking
…-nullchecking

Merge master to features/param-nullchecking
…-nullchecking

Merge master to features/param-nullchecking
…-nullchecking

Merge master to features/param-nullchecking
…-nullchecking

Merge master to features/param-nullchecking
…-nullchecking

Merge master to features/param-nullchecking
…-nullchecking

Merge master to features/param-nullchecking
…-nullchecking

Merge master to features/param-nullchecking
…-nullchecking

Merge master to features/param-nullchecking
…-nullchecking

Merge master to features/param-nullchecking
…-nullchecking

Merge master to features/param-nullchecking
…-nullchecking

Merge master to features/param-nullchecking
…-nullchecking

Merge master to features/param-nullchecking
…-nullchecking

Merge master to features/param-nullchecking
…-nullchecking

Merge master to features/param-nullchecking
…-nullchecking

Merge master to features/param-nullchecking
…-nullchecking

Merge master to features/param-nullchecking
…-nullchecking

Merge master to features/param-nullchecking
…-nullchecking

Merge master to features/param-nullchecking
…-nullchecking

Merge master to features/param-nullchecking
…-nullchecking

Merge master to features/param-nullchecking
sharwell and others added 19 commits December 14, 2021 08:26
The unit tests were testing against a special mock of
VisualStudioWorkspace, which meant the "real" implementation of
GetFileCodeModel wasn't being used, but instead requests for code model
would just go through a lookup into a dictionary. This commit moves
the MockVisualStudioWorkspace to inherit from VisualStudioWorkspaceImpl
where the actual implementation lies, and then generally cleans up this
area to create things via MEF rather than via direct calls to
constructors of some MEF-produced types.
This returns a ProjectItem from the project system for a file, but in
the case of source generated files we won't be able to do that since
they're not represented by anything the project system knows about.

Coincidently, our unit tests always have been passing null the whole
time so this is something more or less we need to deal with regardless.
Some designers look through the other partial parts of a class to look
for methods that match event handler signatures. Here I'm adding limited
support so you can get a FileCodeModel and CodeElement for things
residing in source generated files.

Unlike regular FileCodeModels that have certain lifetime guarantees and
use our COM weak handle magic, this is keeping the implementation simple
and just returning a new FileCodeModel any time we need one, under the
hopes that the uses of this are rare. If that becomes a problem, we can
refactor the CodeModel cache to deal with these, but there is some
complexity around when we precisely know the document has gone away.
Since CodeModel is very much a legacy API I don't want to spend time
adding complexity until we know we need it.

This also doesn't implement any support for raising change events if
a generator output changes. Again, if that is needed we can update
the diffing code accordingly.
* Resolve PROTOTYPE comments in param null checking

Filed the following issues:
- #58323
- #58322
- #58320

* Remove unnecessary issue link
Improve usability of "enable nullable reference types" refactoring
[main] Update dependencies from dotnet/arcade
Fix failure to propagate cancellation token
…generated-documents-in-codemodel

Support CodeClass2.Parts returning parts in source generated files
Swithc to acquiring the component model on a BG thread.
…tructors (#57780)

Fixes #54583. We do not flow attribute post conditions back to the original slot of passed arguments or receivers, as without a proper in-order visit of the method parameters ensuring that the correct nullabilities are observed at the correct times isn't possible.
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

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.