Support CodeClass2.Parts returning parts in source generated files #58241
Merged
jasonmalinowski merged 4 commits intodotnet:mainfrom Dec 15, 2021
Conversation
These can be used by things other than the project system tests.
1dee96e to
fbabebf
Compare
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.
fee5781 to
f89b4bf
Compare
jasonmalinowski
commented
Dec 15, 2021
| return WorkspaceAndCodeModel.workspace; | ||
| } | ||
|
|
||
| private VisualStudioWorkspace GetExtraWorkspaceToDisposeButNotUse() |
Member
Author
There was a problem hiding this comment.
The VisualStudioWorkspace instance is now created by the MEF container, which will dispose it when we dispose the container itself.
|
|
||
| var documentFilePath = GetFilePath(documentId); | ||
| if (documentFilePath == null) | ||
| var document = _threadingContext.JoinableTaskFactory.Run(() => CurrentSolution.GetDocumentAsync(documentId, includeSourceGenerated: true).AsTask()); |
Contributor
There was a problem hiding this comment.
:(
is this on UI thread? does this mean we're now blocking hte UI thread on unbounded source-generator work?
Member
Author
There was a problem hiding this comment.
That's not new, in essence: any CodeModel operation is going to be asking for semantics, which will block.
Member
Author
There was a problem hiding this comment.
Chatting with @CyrusNajmabadi offline, we also realized that in many cases they only way you get here is already having ran generators. i.e. you won't have known there's a DocumentId for the source generated file in the first place without generators having ran.
| else if (_isSourceGeneratedOutput) | ||
| { | ||
| document = State.ThreadingContext.JoinableTaskFactory.Run( | ||
| () => Workspace.CurrentSolution.GetSourceGeneratedDocumentAsync(GetDocumentId(), CancellationToken.None).AsTask()); |
CyrusNajmabadi
approved these changes
Dec 15, 2021
| { | ||
| // Unlike for "regular" documents, we make no effort to cache these between callers or hold them for longer lifetimes with | ||
| // events. | ||
| return FileCodeModel.Create(GetCodeModelCache().State, parent: null, sourceGeneratedDocument.Id, isSourceGeneratorOutput: true, new TextManagerAdapter()).Handle; |
Contributor
There was a problem hiding this comment.
do you want to CWT this?
Member
Author
There was a problem hiding this comment.
I could, I didn't want to do any caching at all just to keep things simple.
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
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.