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.
This pull request makes a couple of changes to
`HoverFactory.GetHoverAsync(...)` to prepare for co-hosting:
1. `HoverFactory.GetHoverAsync(...)` returns an LSP `Hover` rather than
`VSInternalHover`.
2. `HoverFactory.GetHoverAsync(...)` no longer takes a document file
path. It already takes a `RazorCodeDocument`, and the file path can be
retrieved from that.
* Add RemoteClientCapabilities service
The service gets initialized once during initial connection / init and provides client capabilities to other remote services.
* Add RemoteClientCapabilitiesService
- Adding client capabilities to RemoteClientLSPInitializationOptions
- Converting IRemoteClientIntializationService to be a JSON service for simplicity of data serialization
- Converting client initialization code to use JSON client to call IRemoteClientIntializationService
* Fixing tests
* Removing unneeded class
* Fixing tests
* Export IClientCapabilitiesService and consume it when appropriate
Only consumers that are initializing capabiilities service by calling SetCapabilities should be importing it via RemoteClientCapabilitiesService. All other consumers should be using IClientCapabilitiesService.
* Simplifying code, moving and correcting comment
* Test fixup per PR feedback
* Service rename per PR feedback
* More PR feedback
- Renaming a variable
- Made UpdateClientLSPInitializationOptions mode complete (so it updates RemoteSemanticTokensLegendService now with initialization data)
- Removed limitation of single update on RemoteSemanticTokensLegendService
- Use UpdateClientLSPInitializationOptions in cohost semantic tokens test
* Removed unused service
Currently telemetry is flushed after the language server host exits in VS Code. This is correctly flushing to the telemetry session, but can miss actually reporting the telemetry. In VS the lifetime of the TelemetrySession is managed centrally, but in VS Code it is up to each process to make sure it gets disposed properly. Without this telemetry that is fired could be dropped. This change addresses this by doing the following:
Removing the flush method on ITelemetryReporter
Making TelemetryReporter IDisposable (again). This will be disposed by the DI container.
Keep the DI container (ExportProvider) alive in rzls until the language server host exits.
This should fix the reliability of some telemetry getting dropped. It still won't fix the scenario where the user force closes the process but better aligns VS and VS Code in expectation of lifetime management.
I noticed this while trying to set up dashboards. There are not nearly as many events as would be expected. If this still continues to be an issue one more option would be to flush on a timer. The data itself is aggregated and should handle that nicely.
These tests had been changed to set up mocks with DisposalToken from the testing infrastructure. However, the product code being tested doesn't have access to that CancellationToken and always passes CancellationToken.None to the method being mocked.
This is an automatically generated pull request from release/dev17.13
into main.
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:
- https://github.com/dotnet/razor/find/release/dev17.13
- https://github.com/dotnet/razor/find/main
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.
``` bash
git fetch --all
git checkout -t upstream/merges/release/dev17.13-to-main
git reset --hard upstream/main
git merge upstream/release/dev17.13
# Fix merge conflicts
git commit
git push upstream merges/release/dev17.13-to-main --force
```
Fixes https://github.com/dotnet/razor/issues/11112
Hopefully fixes
https://devdiv.visualstudio.com/DevDiv/_workitems/edit/2290299/ but I'm
not sure, as whilst OnAutoInsert was definitely broken for me, it didn't
cause that repro. It just sent telemetry for a fault and did nothing in
the IDE.
Fixes
https://developercommunity.visualstudio.com/t/Razor-editor-is-broken-in-1712-Preview-/10777527
~but awaiting confirmation that FUSE is on for the user who reported the
issue (@richardhauer I don't suppose that's you?)~
Fixes https://dev.azure.com/devdiv/DevDiv/_workitems/edit/2294069
Sadly, in order to get a working test for this, I had to enable FUSE in
cohosting. I say sadly because whilst it proves the cohosting tests are
awesome, it does potentially break us into jail a little bit. But only
in cohosting, so it's a pretty small jail :)
The changes aren't very exciting, as this is just
https://github.com/dotnet/razor/pull/10967 but for more than code
actions (and these changes probably should have been part of that PR
originally 🤦♂️), but each commit has an explanation for why it's there
so commit-at-a-time might be enlightening. I could not resist a little
clean up, but what's one little deleted service between friends?
Since this service was written, IDocumentSnapshot has been updated such that now, all implementations just passed true for a parameter that is part of the existing API
This was returning the passed in changes, which were for a C# document, when the formatting engine should be producing changes for the Razor document, so that was wrong. Additionally, the guard itself was wrong
Previously this was using a boolean flag that I thought was the correct pivot point, but I was wrong, and it made things very confusing. This is much clearer, and more importantly, correct. Essentially if we are trying to format and we get passed a C# edit, then we can't force design time or it would be a different document than the original edit came from, if FUSE is on.
This change moves all of the logic that computes a `VSInternalHover` to
the Workspaces layer. The file diff shouldn't be too bad, but a lot of
code is moved without much additional clean up. So, it might be easier
to go commit-by-commit.
* Update Roslyn package references to latest available and do minor fixup
* Updating Versions.Details.xml to match Versions.props
* PR suggestion
* Fixing test failures
Roslyn was requesting new IRazorMappingService and our TestRazorDocumentServiceProvider was throwing. Returning null for now per suggestion from Andrew.
* Adding TODO comment per code review
Alex Gavrilov (DEV PROD)
Ankita Khera
Dustin Campbell
Andrew Hall
David Wengier
dotnet bot
earloc