Reenable LSP pull diagnostics#48328
Conversation
…spDiagnostics"" This reverts commit 02a9e20.
|
@CyrusNajmabadi when you have time, this will need latest master merged in to fix the failures (or let me know and I can update your branch) edit - nvm it isn't merged in yet - spoke too soon! |
|
|
||
| var buckets = _diagnosticService.GetDiagnosticBuckets( | ||
| workspace, document.Project.Id, document.Id, context.CancellationToken); | ||
| workspace, document.Project.Id, document.Id, forPullDiagnostics: false, context.CancellationToken); |
There was a problem hiding this comment.
an intermediary concept this PR introduces is that the two major clients of the diagnostics subsystem now pass in what behavior they want when calling into the DiagnosticService singleton.
i.e. the normal push features call in saying forPullDiagnostics: false and the lsp system calls in saying forPullDiagnostics: true. Internally we see which mode we're actually in and we either pass along the diagnostics, or pass along empty. in essence only one side will work, and the other will see absolutely no diagnostics ever.
This is not pretty, but it was:
- the cleanest way i could find to keep both systems around
- required minimal and mechanical changes to both systems.
- ensured that every entrypoint was guarded so diagnostics wouldn't accidentally sneak into the wrong client.
Once we are entirely on pull, all the push components can go away (as can tehse booleans).
src/EditorFeatures/TestUtilities/LanguageServer/AbstractLanguageServerProtocolTests.cs
Show resolved
Hide resolved
| // If this is a pull client, but pull diagnostics is not on, then they get nothing. Similarly, if this is a | ||
| // push client and pull diagnostics are on, they get nothing. | ||
| if (forPullDiagnostics != workspace.Options.GetOption(InternalDiagnosticsOptions.LspPullDiagnostics)) | ||
| return ImmutableArray<DiagnosticData>.Empty; |
There was a problem hiding this comment.
this is one of 3 main entrypoints that now ensures the right data flows out depending on the caller's needs. If the caller doesn't match the current diagnostics-mode we're in (either 'push' or 'pull') they get nothing back. This allows DiagnosticService to still be the centralized authority that everyone uses.
| // If this is a pull client, but pull diagnostics is not on, then they get nothing. Similarly, if this is a | ||
| // push client and pull diagnostics are on, they get nothing. | ||
| if (forPullDiagnostics != workspace.Options.GetOption(InternalDiagnosticsOptions.LspPullDiagnostics)) | ||
| return ImmutableArray<DiagnosticBucket>.Empty; |
There was a problem hiding this comment.
second (of three) entrypoint that is updated.
| // If this is a pull client, but pull diagnostics is not on, then they get nothing. Similarly, if this is a | ||
| // push client and pull diagnostics are on, they get nothing. | ||
| if (forPullDiagnostics != workspace.Options.GetOption(InternalDiagnosticsOptions.LspPullDiagnostics)) | ||
| return ImmutableArray<DiagnosticData>.Empty; |
There was a problem hiding this comment.
third (of three) entrypoint that was updated.
| internal abstract class AbstractLanguageServerClient : ILanguageClient | ||
| { | ||
| private readonly string? _diagnosticsClientName; | ||
| private readonly IDiagnosticService _diagnosticService; |
There was a problem hiding this comment.
all the lsp push diagnostic code is removed with this PR.
There was a problem hiding this comment.
The client is now sending a capability that tells us whether they support pull diagnostics (https://devdiv.visualstudio.com/DevDiv/_git/VSLanguageServerClient/pullrequest/279454?_a=files) so if that is false, we should keep this code running.
| } | ||
|
|
||
| return ImmutableArray<LSP.Diagnostic>.Empty; | ||
| } |
There was a problem hiding this comment.
yaay deleted code.
There was a problem hiding this comment.
Super happy to delete this code - but this means that in order for razor to get diagnostics, they will have to set the feature flag to LSP diagnostics for regular c# files as well right? I'm OK with that but wanted to make sure that is the goal
| { | ||
| foreach (var bucket in diagnosticService.GetDiagnosticBuckets(workspace, projectId: null, documentId: null, cancellationToken: CancellationToken.None)) | ||
| var diagnostics = diagnosticService.GetDiagnosticBuckets( | ||
| workspace, projectId: null, documentId: null, forPullDiagnostics: false, cancellationToken: CancellationToken.None); |
There was a problem hiding this comment.
All existing code calls forPullDiagnostics: false.
| var text = await document.GetTextAsync(cancellationToken).ConfigureAwait(false); | ||
| using var _ = ArrayBuilder<VSDiagnostic>.GetInstance(out var result); | ||
|
|
||
| var diagnostics = _diagnosticService.GetDiagnostics(document, includeSuppressedDiagnostics: false, forPullDiagnostics: true, cancellationToken); |
There was a problem hiding this comment.
this is new code. it calls forPullDiagnostics: true as it wants to only run if we're explicitly opted-into pull mode.
…ming them in LSP scenarios.
dibarbet
left a comment
There was a problem hiding this comment.
a few comments, but nothing blocking!
src/Features/Core/Portable/Diagnostics/DiagnosticsUpdatedArgs.cs
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Yep this looks good!
Do we want to conditionally set this capability based on the feature flag? That way we can avoid having the client even call into us if it's off. Might be too minor of an optimization though.
| } | ||
|
|
||
| return ImmutableArray<LSP.Diagnostic>.Empty; | ||
| } |
There was a problem hiding this comment.
Super happy to delete this code - but this means that in order for razor to get diagnostics, they will have to set the feature flag to LSP diagnostics for regular c# files as well right? I'm OK with that but wanted to make sure that is the goal
Co-authored-by: David <dibarbet@gmail.com>
…oslyn into lspDiagnostics2
Yes. That seems reasonable :) |
Yeah, i'm ok with that :) |
This reverts commit 02a9e20.