[LSP] Remove the majority of usages of client name.#60357
[LSP] Remove the majority of usages of client name.#60357dibarbet merged 5 commits intodotnet:mainfrom
Conversation
…return results for what it was asked for while the platform is responsible for asking for the correct buffers based on client name.
966e84d to
1b34646
Compare
|
Will this mean the AlwaysActive language server will get requests to Razor C# buffers if we don't specifically target the Razor C# LSP server? |
| using System.Threading; | ||
| using System.Threading.Tasks; | ||
| using Microsoft.CodeAnalysis.Classification; | ||
| using Microsoft.CodeAnalysis.ExternalAccess.Razor.Api; |
@NTaylorMullen this doesn't change the behavior of what the client asks for - we still export our ILC with the client name and expect the buffer to have it. But on the server side now we assume that the client knows what it wants and answer the request without filtering by client name. The client is already asking the razor server for razor C# and the normal C# to the C# server (we would be seeing a ton of errors in logs and telemetry if that were not the case). There did used to be bugs in liveshare where the client did request all servers for razor C#, but they have since been fixed. |
|
/azp run |
|
Azure Pipelines successfully started running 4 pipeline(s). |
|
https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1505437 is merged, waiting on new build to test |
verified, working as before |
There was previously a bug where both the liveshare c# server and razor c# server were asked for results in a liveshare session. It has since been resolved so I no longer see the need to carry around the majority of the client name complexity that we had.
Instead of filtering documents by client name, we just respond with what we have that matches the URI. It is up to the client to appropriately delegate to the correct server.
This at least reduces the complexity in my brain when I try and reason about how we map URIs -> documents.
The usages of client name that still remain are essentially only for diagnostic purposes. We use it to
a) prevent razor file diagnostics from going to the error list (razor always asks us for them)
b) always calculate razor file diagnostics regardless of if the file is 'open' or not (when asked by razor)
c) prevent razor file diagnostics from being returned in LSP workspace pull diagnostics from the C# server (again, razor will directly ask us for diagnostics if and when they need them).
Can't merge until https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1505437 is fixed so I can verify liveshare