-
Notifications
You must be signed in to change notification settings - Fork 4k
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
Flip 'pull diagnostics' to be on by default. #70040
Flip 'pull diagnostics' to be on by default. #70040
Conversation
The text "experimental" needs to be removed from the option name at the same time. |
Indeed! |
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.
Requesting this be blocked on #65967. In its current form, LSP pull diagnostics does not work at all.
Fixes dotnet#65967 Prior to this change, Run Code Analysis command force executed all the analyzers on the selected project/solution, but the reported analyzer diagnostics were not getting reported from LSP pull handlers. This PR makes the following changes to ensure these diagnostics get reported as workspace pull diagnostics: 1. Modify WorkspacePullDiagnosticHandler so that it reports diagnostics when either of the following conditions are met: 1. Full solution analysis is enabled (it was already doing so prior to this PR) 2. Project was already force analyzed and has cached diagnostics (it could be via Run Code Analysis command or any other client in future). 2. Update the Workspace and Project diagnostic sources added by the Workspace pull handler to do the following: 1. If full solution analysis is enabled, compute and report the closed file diagnostics for the latest solution snapshot 2. Otherwise, return the already cached closed file diagnostics, which may be from a prior snapshot (this matches the non-LSP behavior when Run Code Analysis command is executed) 3. Update the `DiagnosticAnalyzerService.ForceAnalyzeAsync` command that is invoked during Run Code Analysis to keep track of projects that were force analyzed. Additionally, also send a workspace diagnostic refresh request to the LSP client after each project has finished analysis. With the above changes, Run Code Analysis command executes and reports diagnostics as expected in LSP pull diagnostics mode. There is still a considerable delay (10 sec) in error list getting populated with diagnostics from this command as the workspace diagnostic refresh is triggered at a delay. We will be addressing this in a separate follow-up change, where in we will trigger a new kind of diagnostic refresh request specifically catered to code analysis execution, such that the client does the workspace pull without any delay. We are still unsure if we need to pass in the project context around in this refresh request OR let it be a full refresh, given the server is only going to attempt to return workspace diagnostics from the cache, so a full refresh request may not incur any significant cost. TBD: Add unit tests for this scenario. I am going to do this in a follow-up PR so that dotnet#70040 does not stay blocked on the product changes here.
Changes have gone in on the platform and in CPS.
I have been really trying to see a case where Pull Diagnostics works, but to date I haven't been able to use it for more than a few minutes before I reach a time box and have to turn it off to get work done. I'll give it another try this week, but I haven't seen any evidence to suggest this feature is ready for delivery. |
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.
speedometer passed, we still have the feature flag we can use to turn this off.
OK with this going in, just need to make sure the feature flag is sync'd with this default
src/VisualStudio/IntegrationTest/New.IntegrationTests/CSharp/CSharpCodeActions.cs
Show resolved
Hide resolved
src/VisualStudio/IntegrationTest/New.IntegrationTests/CSharp/CSharpCodeActions.cs
Show resolved
Hide resolved
@@ -122,7 +121,7 @@ private static string GetMessage(ITableEntryHandle item) | |||
var unknown => unknown.ToString(), | |||
}; | |||
|
|||
var message = $"({source}) {document}({line + 1}, {column + 1}): {severity} {errorCode}: {text}"; |
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.
Why was this changed?
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.
'source' is not a thing anymore. we previously placed it in this info just so we could distinguish if we made the error item based on live items vs build items.
var tags = aggregator | ||
.GetTags(new SnapshotSpan(view.TextSnapshot, 0, view.TextSnapshot.Length)); | ||
|
||
return tags.SelectAsArray(tag => new TagSpan<IErrorTag>(tag.Span.GetSpans(view.TextBuffer).Single(), tag.Tag)); |
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.
How is this different from what it did before?
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.
the other codepath converts the tags to IMappingTagSpans, which these new editor tags do not impl.
Assert.Equal(expectedTags.Length, actualTags.Length); | ||
for (var i = 0; i < expectedTags.Length; i++) | ||
while (true) | ||
{ | ||
var expectedTag = expectedTags[i]; | ||
var actualTaggedSpan = actualTags[i]; | ||
Assert.Equal(expectedTag.errorType, actualTaggedSpan.Tag.ErrorType); | ||
Assert.Equal(expectedTag.textSpan.Start, actualTaggedSpan.Span.Start.Position); | ||
Assert.Equal(expectedTag.textSpan.Length, actualTaggedSpan.Span.Length); | ||
|
||
var actualTaggedText = actualTaggedSpan.Span.GetText(); | ||
Assert.Equal(expectedTag.taggedText, actualTaggedText); | ||
|
||
AssertEx.NotNull(actualTaggedSpan.Tag.ToolTipContent); | ||
var containerElement = (ContainerElement)actualTaggedSpan.Tag.ToolTipContent; | ||
var actualTooltipText = CollectTextInRun(containerElement); | ||
Assert.Equal(expectedTag.tooltipText, actualTooltipText); | ||
cancellationToken.ThrowIfCancellationRequested(); | ||
await Task.Delay(TimeSpan.FromSeconds(1)); |
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.
Need to wait directly for pull diagnostics
// return GetTagsAsync<IErrorTag>(cancellationToken); | ||
|
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.
// return GetTagsAsync<IErrorTag>(cancellationToken); |
@dibarbet this has been merged in. We'll track the insertion to deal with targeted notifications. |
submitted the targeted notification change to get CPS onto the same place |
We've had this on internally for a while, and since all recent fixes have gone through, have not heard any complaints about the diagnostics experience.
We'd like to enable this early for everyone to get this out there for everyone to use. Note: this comes with a feature-flag we can use to switch back to the non-pull (solutioncrawler model) in case we discover issues. Once we've had enough time with people using the default (like a full point release), we can start removing the older systems.
PR: https://devdiv.visualstudio.com/DefaultCollection/DevDiv/_build/results?buildId=8713552&view=results
Build: https://dev.azure.com/devdiv/DevDiv/_git/VS/pullrequest/512411
PR: https://devdiv.visualstudio.com/DefaultCollection/DevDiv/_build/results?buildId=8730199&view=results