-
Notifications
You must be signed in to change notification settings - Fork 196
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
Adding cohost completion handler #11048
Conversation
…letionItemProvider to common layer.
…ded by RemoteCompletionService
Switch passed in and returned types from Roslyn to VS Platform LSP types since that's what all of the common completion code in the Workspaces layer uses. We will need to convert returned Roslyn completion items to VS platform LSP completion items.
…et used in cohosting
…e workspaces layer (to be used in cohosting later)
…g HTML completion item labels to RazorCompletionListProvider
…r and minor cleanup
… layer and use it in cohost completion request
Also simplifying parameters passed to the response re-writers to only what's needed.
…hooked up and we are getting VSInternalCompletionContext in CompletionParams
…ng them They all already checked (or should've checked) for language and were operating on either C# or HTML, never on both. HTML re-writer will get called from the client and can be much simpler. In cohosting it doesn't make sense to have them all in one list since C# will get called in OOP and HTML on the client (in VS).
… it up in cohosting
Renamed some fields and variables dealing with "add snippets" options and added comments. We currently have two options that mean "add snippets" - one for the delegated completion, and one for Razor completion. The values of those don't correlate. The Razor one is always true in LSP and Cohost, always false for legacy editor. The delegation one actually depends on the position.
Also adding a snippet completion provider test and markup transition test
This should probably move to the common test project eventually, but not in this PR. Moving this to the workspaces layer caused many changes in unrelated test files and changed test project references. Per PR feedback leaving this in the LanguageServer.Test project for now. We can refactor later as appropriate.
I noticed some painful NuGet analyzer package upgrades in PR #11048 and decided to take a look at the issue. I've made the following changes: - `Roslyn.Diagnostics.Analyzers` is now versioned separately from `Microsoft.CodeAnalysis.Analyzers`, as they are in [`dotnet/roslyn`](https://github.com/dotnet/roslyn/blob/08243d3826b8ebbc38350d0d74796bb8176f55b1/eng/Directory.Packages.props#L4). - I've removed direct references to `MS.CA.BannedApiAnalyzers` since that reference should flow from `Roslyn.Diagnostics.Analyzers`. - I've updated the versions of `Microsoft.CodeAnalysis.Analyzers` and `Roslyn.Diagnostics.Analyzers`
Hardcoding true for now until we plumb this through Initialize. Fixes osolete API build break
Thanks! In reply to: 2380188950 |
…n set more obvious
src/Razor/src/Microsoft.AspNetCore.Razor.LanguageServer/Completion/RazorCompletionEndpoint.cs
Show resolved
Hide resolved
src/Razor/src/Microsoft.CodeAnalysis.Razor.Workspaces/Completion/CompletionTriggerCharacters.cs
Show resolved
Hide resolved
src/Razor/src/Microsoft.CodeAnalysis.Razor.Workspaces/Completion/CompletionTriggerCharacters.cs
Show resolved
Hide resolved
src/Razor/src/Microsoft.CodeAnalysis.Razor.Workspaces/DocumentMapping/DocumentPositionInfo.cs
Outdated
Show resolved
Hide resolved
src/Razor/src/Microsoft.CodeAnalysis.Remote.Razor/Completion/RemoteCompletionService.cs
Outdated
Show resolved
Hide resolved
...isualStudio.LanguageServices.Razor/LanguageClient/Cohost/CohostDocumentCompletionEndpoint.cs
Outdated
Show resolved
Hide resolved
...isualStudio.LanguageServices.Razor/LanguageClient/Cohost/CohostDocumentCompletionEndpoint.cs
Show resolved
Hide resolved
...soft.VisualStudio.LanguageServices.Razor.Test/Cohost/CohostDocumentCompletionEndpointTest.cs
Show resolved
Hide resolved
Instead of passing client capabilities with each call to RemoteCompletionService we can now use remote IClientCapabilitiesService that's initialized with client capabilities on initial connection.
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.
Approving as requested, though somewhat reluctantly.
I hope to see follow up PRs soon, and I would love to see a little more care and attention in them. Try running Format Document on things before committing, try planning ahead if you want to do smaller PRs, etc. etc.
Summary of the changes
I tried making each commit small and serving a single purpose, so looking commit-by-commit could be helpful, though returned data in each individual commit is not going to be correct, especially in the first few commits. A lot of merging, filtering and ordering was added in the last few commits to ensure correct final completion list is returned.
One unfortunate thing here is conversion between VS and Roslyn LSP types that we have to do until we move to Roslyn LSP types everywhere in our code. Completion code uses LSP types throughout most of the common code much more so than other requests, and while we need common code for non-cohost LSP endpoint, most of it has to use VS LSP types for now.
Fixes: #11100