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

Make diagnostic checksum computation into an extension method. #77277

Open
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

CyrusNajmabadi
Copy link
Member

@CyrusNajmabadi CyrusNajmabadi commented Feb 19, 2025

@dotnet-issue-labeler dotnet-issue-labeler bot added Area-IDE untriaged Issues and PRs which have not yet been triaged by a lead labels Feb 19, 2025
@CyrusNajmabadi CyrusNajmabadi marked this pull request as ready for review February 20, 2025 09:28
@CyrusNajmabadi CyrusNajmabadi requested a review from a team as a code owner February 20, 2025 09:28
@CyrusNajmabadi
Copy link
Member Author

@jasonmalinowski @dibarbet this is ready for review.

@ToddGrun
Copy link
Contributor

Is the motivation for this just to simplify the implementation?

return _lazyDependentChecksum.GetValueAsync(cancellationToken);
}

private async Task<Checksum> ComputeDependentChecksumAsync(SolutionCompilationState compilationState, CancellationToken cancellationToken)
Copy link
Contributor

Choose a reason for hiding this comment

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

ComputeDependentChecksumAsync

Am I reading this right in that the old code would potentially reuse the cached checksum from the underlying tracker and only need to get new checksum information from _replacementDocumentStates?

Copy link
Member Author

Choose a reason for hiding this comment

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

Correct. But I don't think the complexity is worth it. Having the new system operate uniformly on any Project instance is more desirable for me.

// Calculate a checksum this project and for each dependent project that could affect semantics for this
// project. We order the projects guid so that we are resilient to the underlying in-memory graph structure
// changing this arbitrarily.
foreach (var projectRef in project.ProjectReferences.OrderBy(r => r.ProjectId.Id))
Copy link
Contributor

Choose a reason for hiding this comment

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

ProjectReferences

I don't think it's a problem, but this could hit repeat projects during the recursion, whereas it wouldn't have before, right?

Copy link
Member Author

Choose a reason for hiding this comment

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

We shouldn't have any repeats afaict.

Copy link
Member Author

Choose a reason for hiding this comment

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

Note: an the expensive checksumming will be cached (at the ProjectState level). All this is doing is mixing the checksums together to make the final checksum.

We honestly could even consider not caching this. I was a bit nervous about going that much, in case of LSP where we might have N requests on the same Project.

@@ -21,6 +22,8 @@ namespace Microsoft.CodeAnalysis.Diagnostics;

internal static partial class Extensions
{
private static readonly ConditionalWeakTable<Project, AsyncLazy<Checksum>> s_projectToDiagnosticChecksum = new();
Copy link
Contributor

@ToddGrun ToddGrun Feb 20, 2025

Choose a reason for hiding this comment

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

ConditionalWeakTable

For my understanding:

I thought generally it was best to avoid CWTs unless it was quite difficult not to do so as they add extra strain to GC. Is this not the case?

Copy link
Member Author

Choose a reason for hiding this comment

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

So I didn't think there would be an issue with cwt here given how few keys there would be.

We can definitely run speedometer to see if there are concerns here

@CyrusNajmabadi
Copy link
Member Author

Is the motivation for this just to simplify the implementation?

That's a large part yes. Also, to not depend as much on internal data which is easier to get wrong.

@CyrusNajmabadi
Copy link
Member Author

Kicked off pipeline.

@CyrusNajmabadi
Copy link
Member Author

No issues found. @ToddGrun ptal.

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 VSCode
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants