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

Change RazorSyntaxTree.Diagnostics from an IReadOnlyList<RazorDiagnostic> to an ImmutableArray<RazorDiagnostic> #10797

Merged
merged 15 commits into from
Sep 4, 2024

Conversation

DustinCampbell
Copy link
Member

This pull request represents several changes with the ultimate goal of exposing RazorSyntaxTree.Diagnostics as an ImmutableArray<RazorDiagnostic> rather than an IReadOnlyList<RazorDiagnostic>:

  • Clean up RazorSyntaxTree and get rid of DefaultRazorSyntaxTree.
  • Add (Drain)ToImmutableOrdered* methods to PooledArrayBuilder<T>. Note that this change also includes a refactoring to the various unit tests for ordering to share test data that I've isolated to a single commit.
  • Clean up and improve ErrorSink to no longer greedily create a new List<T> before any errors are encountered.
  • Clean up ParserContext and make it used pooled collections.
  • Use pooled collections when computing and caching the result of RazorSyntaxTree.Diagnostics.

- Use pooled `ImmutableArray<RazorDiagnostic>.Builder` internally
- Don't request pooled builder until first error is added
- Make ErrorSink disposable to return builder to pool
- Add GetErrorsAndClear() method to returns an `ImmutableArray<RazorDiagnostic>` and clears out the sink.
- Add 'ParserContext.PushNewErrorScope(...)` to handle the temporary ErrorSinks used by CSharpCodeParser
This change cleans up ParserContext a bit and uses pooled collections within it.
@DustinCampbell DustinCampbell requested review from a team as code owners August 27, 2024 18:14
Copy link
Contributor

@davidwengier davidwengier left a comment

Choose a reason for hiding this comment

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

✅ Tooling

@@ -1333,4 +1333,196 @@ private void MoveInlineItemsToBuilder()
// Since _inlineCount tracks the number of inline items used, we zero it out here.
_inlineCount = 0;
}

public readonly ImmutableArray<T> ToImmutableOrdered()
Copy link
Contributor

Choose a reason for hiding this comment

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

I was looking for these methods just yesterday, and I couldn't find them, but knew I'd seem them somewhere. The mystery is solved! :D

Copy link
Contributor

@chsienki chsienki left a comment

Choose a reason for hiding this comment

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

LGTM. I think every time I saw something I wanted to comment on, you fixed it in the next commit :)

Copy link
Member

@333fred 333fred left a comment

Choose a reason for hiding this comment

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

Thanks as always for the meticulous commit history Dustin, it significantly helps make these reviews easy. Only one small testing comment, otherwise everything LGTM.

It is perfectly legal for a PooledArrayBuilder<T> to be drained via one of the DrainToImmutable* methods and then continue adding items to the builder. However, if the inner ImmutableArray<T>.Builder's capacity was set to 0 during the drain, its capacity will not be reset to any specified value when adding new items. This change fixes that.
@DustinCampbell DustinCampbell merged commit 90b1855 into dotnet:main Sep 4, 2024
12 checks passed
@DustinCampbell DustinCampbell deleted the syntax-tree-diagnostics branch September 4, 2024 15:41
@dotnet-policy-service dotnet-policy-service bot added this to the Next milestone Sep 4, 2024
@phil-allen-msft phil-allen-msft modified the milestones: Next, 17.12 P3 Oct 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants