Skip to content
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

Ensure diagnostics are logged before proceeding with further project loading #70467

Merged
merged 3 commits into from
Oct 25, 2023

Conversation

dibarbet
Copy link
Member

@dibarbet dibarbet commented Oct 19, 2023

Related to dotnet/vscode-csharp#6356

Diagnostics were retrieved on the first step of project loading, but logged at the end after the rest of the steps. This meant if there was a diagnostic in the first step that didn't outright fail, but caused a later step to fail we wouldn't log it.

@dibarbet dibarbet requested a review from a team as a code owner October 19, 2023 22:25
@dotnet-issue-labeler dotnet-issue-labeler bot added Area-IDE untriaged Issues and PRs which have not yet been triaged by a lead labels Oct 19, 2023
@@ -205,6 +206,15 @@ private async Task<(LSP.MessageType? failureType, BuildHostProcessKind? preferre
if (await buildHost.IsProjectFileSupportedAsync(projectPath, cancellationToken))
{
var loadedFile = await buildHost.LoadProjectFileAsync(projectPath, cancellationToken);
var diagnosticLogItems = await loadedFile.GetDiagnosticLogItemsAsync(cancellationToken);
LogDiagnostics(projectPath, diagnosticLogItems);
Copy link
Member

@jasonmalinowski jasonmalinowski Oct 20, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One subtle bit: unfortunately how the existing code works is all the diagnostics created for loading get dumped into the same collection, both for evaluation and execution passes. So you probably only want to call LogDiagnostics() if you're in your if check and bailing; otherwise you can have the later LogDiagnostics() call. If both places call it though Warnings might get logged twice.

We should also make LogDiagnostics() just return the most severe type of LSP.MessageType so we can inline that.

_logger.Log(logItem.Kind is WorkspaceDiagnosticKind.Failure ? LogLevel.Error : LogLevel.Warning, $"{logItem.Kind} while loading {logItem.ProjectFilePath}: {logItem.Message}");
}

return diagnosticLogItems.Any(logItem => logItem.Kind is WorkspaceDiagnosticKind.Failure) ? LSP.MessageType.Error : LSP.MessageType.Warning;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: if you're already doing the loop you could just have a local of severity you assign warning, and while in the existing loop just change it to error on failure. Or leave it looping twice, not a big deal I don't think.

@jasonmalinowski jasonmalinowski merged commit 6d859c2 into dotnet:main Oct 25, 2023
22 of 24 checks passed
@ghost ghost added this to the Next milestone Oct 25, 2023
@dibarbet dibarbet deleted the fix_error_logging branch October 25, 2023 04:25
@jjonescz jjonescz modified the milestones: Next, 17.9 P1 Oct 31, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-IDE untriaged Issues and PRs which have not yet been triaged by a lead
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants