Fixes#10839
Now that all of the infrastructure is in place, adding a co-hosting
endpoint and remote service for Hover is mostly boilerplate. Similar to
the signature help endpoint, the result type might be a Roslyn LSP Hover
or a VS LSP Hover. The remote service always returns a Roslyn LSP Hover,
but HTML will return a VS LSP Hover. So, we join the possibilities
together with a SumType.
This change is a follow-up to
https://github.com/dotnet/razor/pull/11144#discussion_r1828602406 that
addresses two issues that may help with diagnosis:
1. `Assumed.Unreachable(...)`captures the `[CallerFilePath]` and
`[CallerLineNumber]` but didn't do anything with them. Now, those values
are appended to the exception message.
2. Two `Assumed.Unreachable(...)` overloads have been added to allow a
custom exception message to be provided that can be used to add more
detail about a failure.
These tests detect an issue I ran into doing code actions, and Dustin
ran into doing hover.
Also makes it impossible to forget to specify a `DocumentSelector` in a
registration.
This is the pull request automatically created by the OneLocBuild task
in the build process to check-in localized files generated based upon
translation source files (.lcl files) handed-back from the downstream
localization pipeline. If there are issues in translations, visit
https://aka.ms/icxLocBug and log bugs for fixes. The OneLocBuild wiki is
https://aka.ms/onelocbuild and the localization process in general is
documented at https://aka.ms/AllAboutLoc.
Rework the logic in RemoteHoverService. It isn't necessary to try and map the host document index to C#, since `GetPositionInfo(..., preferCSharpOverHtml: true)`already does that for us.
This change addresses two issues that may help with diagnosis:
1. `Assumed.Unreachable(...)`captures the `[CallerFilePath]` and `[CallerLineNumber]` but didn't do anything with them. Now, those values are appended to the exception message.
2. Two `Assumed.Unreachable(...)` overloads have been added to allow a custom exception message to be provided that can be used to add more detail about a failure.
* Basic infrastructure and HTML completion
* Moving CompletionListCache into common code
* Moved RazorCompletionListProvider and supporting infrustructure to common code
* Adding OOPRazorCompletionFactsService and moving MarkupTransitionCompletionItemProvider to common layer.
* Moving LspTagHelperCompletionService to common layer
* Move RazorCompletionListProvider to the Workspaces layer
* Add OOP MEF exports for completion services from Workspaces layer needed by RemoteCompletionService
* Hook up RazorComplelistListProvider in the 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.
* Bump Roslyn version to get new CSharp completion APIs
* Hooking up C# completion API
* Common code for completion trigger characters and correct character set used in cohosting
* Respect AutoShowCompletion setting in cohosting
* Move IsValidTrigger method to CompletionTriggerCharacters class in the workspaces layer (to be used in cohosting later)
* Call HTML completion only if we are in HTML and pass a set of existing HTML completion item labels to RazorCompletionListProvider
* Pass C# existing completion item labels to RazorCompletionListProvider and minor cleanup
* Final completion list merge logic
* Move delegated completion helper RewriteContext method into Workspace layer and use it in cohost completion request
* Provisional completion support
* Moving delegated response rewriters to the common layer
* Consuming delegated completion response re-writers in C#
Also simplifying parameters passed to the response re-writers to only what's needed.
* Switch to Roslyn CompletionParams as request input so converters are hooked up and we are getting VSInternalCompletionContext in CompletionParams
* Splitting delegated response rewriters into C# and HTML and simplifying 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).
* Moving ShouldIncludeSnippets helper into the common layer and hooking it up in cohosting
* Adding snippets completion support to cohosting
* First part of completion options clean-up
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.
* Second part of completion options clean-up - fixing options values in cohost
* First set of tests
* Adding directives completion provider and test to cohost
* Adding directive and directive attribute completion providers and tests
Also adding a snippet completion provider test and markup transition test
* Adding test for CommitElementsWithSpace option
* Adding test for AutoInsertAttributeQuotes
* Moved most of the tests for moved code from LanguageServer to Workspaces test projects
The tests were left behind (some in this PR, some in prior PRs) when the code was moved to Workspaces layer. This commit addresses most of them other than in Delegation subworkspace
* Fixing delegated response re-writer tests.
We had inconsistent handling of null completion item labels between our response re-writers. Some handled null labels, others would through. Since label shouldn't be null (non-nullable), I adjusted the tests not to use null labels.
Also the tests previously passed because they created DelegatedCompletionListProvider with only a selected DelegatedResponseRewriter. Now the DelegatedCompletionHelper will apply all response re-writers for the correct language (either C# or HTML), which is what the product actually does, so I feel that's fine. It exposed these test failures due to inconsistent null label handling
* Add required cancellation token argument to GetGeneratedDocumentAsync in RemoteCompletionService
* Simplifying trigger character data
Switching AllTriggerCharacters to string[] since we only use it for registration/capability data, which needs string[]. and we never do look ups via Contains. Also removing rendundant property and calculations in CompletionListProvider
* Serialization attribute clean-up
* Converting DelegatedCSharpCompletionResponseRewriter to interface per CR suggestion
* Changing ShouldIncludeSnippets to take in RazorCodeDocument per CR suggestion
* Removed unnecessary null checks per CR suggestion
* PR feedback - ConfigureAwait(false), shared code for commit characters, better collection check
* Simplify applying provisional text edit
* PR test suggestions
* Adding a comment clarifying the reasoning about the return value of OOP code
* Removing item count verification and retries per PR feedback
* Switching to hardcoded directive list in tests per PR feedback
* Moving TagHelperServiceTestBase back to LanguageServer.Test project
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.
* Cleanup per PR feedback
* Fixing build post-merge
* Pass argument for supportsVsExtensions in RemoteDocumentSymbolService
Hardcoding true for now until we plumb this through Initialize. Fixes osolete API build break
* Add Debug.Fail to make the intent of returning null vs empy completion set more obvious
* Cleanup and comments per PR feedback
* One more comment per PR feedback
* Don't avertise Resolve until we provide it
* Removing unnecessary async
* C# override test
* Use remote IClientCapabilitiesService
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.
* Misc cleanup per PR feedback
Add logging on the server side for why a project isn't being serialized.
Reduce some of the logging on the client side if it gets into a bad state. Log once for first bad read and once when it gets to a point where we think we returned to a good state.
My bad. In https://github.com/dotnet/razor/pull/11135 I failed to notice
that the `GenerateRazorCodeActionContextAsync` also modified the
original code actions request, to handle an oddity of VS LSP, where it
sends the users selected range (or cursor position) as a different
property, and uses the `Range` property as the whole line.
Phil Allen
David Wengier
Dustin Campbell
dotnet bot
Alex Gavrilov
Jan Jones
Andrew Hall
dotnet-maestro[bot]