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

Moving formatting service to common layer #10761

Merged
merged 10 commits into from
Aug 21, 2024

Conversation

alexgav
Copy link
Contributor

@alexgav alexgav commented Aug 19, 2024

Summary of the changes

Moving RazorFormattingService to common layer. It's immediately needed for OnAutoInsert support, but will eventually be needed by the formatting endpoints themselves.

Fixes:
Part of #9519

@alexgav alexgav requested a review from a team as a code owner August 19, 2024 05:33
@alexgav alexgav marked this pull request as draft August 19, 2024 05:33
@alexgav alexgav marked this pull request as ready for review August 19, 2024 17:30
@alexgav alexgav marked this pull request as draft August 19, 2024 18:06
@alexgav
Copy link
Contributor Author

alexgav commented Aug 19, 2024

Switching back to draft while I investigate test failures fixed, ready for review

@alexgav alexgav marked this pull request as ready for review August 20, 2024 04:21
@alexgav alexgav force-pushed the dev/alexgav/MoveFormattingServiceToCommonLayer branch from 18d9e8e to 0291c12 Compare August 20, 2024 14:05
Copy link
Member

@DustinCampbell DustinCampbell left a comment

Choose a reason for hiding this comment

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

Other than some minor clean up feedback (that you can take or leave), looks good to me!

@@ -126,7 +128,7 @@ directiveCode.Children is [RazorDirectiveSyntax directive] &&

return false;

static bool TryGetWhitespace(SyntaxList<RazorSyntaxNode> children, [NotNullWhen(true)] out CSharpStatementLiteralSyntax? whitespaceBeforeSectionName, [NotNullWhen(true)] out UnclassifiedTextLiteralSyntax? whitespaceAfterSectionName)
static bool TryGetWhitespace(AspNetCore.Razor.Language.Syntax.SyntaxList<RazorSyntaxNode> children, [NotNullWhen(true)] out CSharpStatementLiteralSyntax? whitespaceBeforeSectionName, [NotNullWhen(true)] out UnclassifiedTextLiteralSyntax? whitespaceAfterSectionName)
Copy link
Member

Choose a reason for hiding this comment

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

Consider adding a using type alias at the type of the file for SyntaxList:

using RazorSyntaxNodeList = Microsoft.AspNetCore.Razor.Language.Syntax.SyntaxList<Microsoft.AspNetCore.Razor.Language.Syntax.RazorSyntaxNode>;

Copy link
Member

Choose a reason for hiding this comment

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

@davidwengier: It feels like some global usings for common type aliases like these might be useful. What do you think?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@davidwengier: It feels like some global usings for common type aliases like these might be useful. What do you think?

I personally would love that for consistency, totally open to suggestions here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Also since there is a list of SyntaxNode and a list of RazorSyntaxNode, I ended up with RazorSyntaxNodeList and RazorRazorSyntaxNodeList :) The latter sound silly though follows the pattern. Suggestions are welcome.

Copy link
Member

Choose a reason for hiding this comment

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

I honestly do not understand why Razor has both SyntaxNode and RazorSyntaxNode. It's very unclear and inconsistent. RazorSyntaxNode inherits directly from SyntaxNode and adds no extra implementation. Most SyntaxNode subtypes in the Razor compiler actually inherit from RazorSyntaxNode. Heck, even CSharpSyntaxNode inherits from RazorSyntaxNode. There are only a few types that directly inherit from SyntaxNode, and I wonder if those are mistakes? For example, SyntaxToken inherits from RazorSyntaxNode but SyntaxTrivia inherits from SyntaxNode? It's all wacky. 😄

Copy link
Member

Choose a reason for hiding this comment

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

Maybe @333fred, @chsienki, or @jjonescz understand some nuance between SyntaxNode and RazorSyntaxNode that I don't see?

Copy link
Member

Choose a reason for hiding this comment

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

I certainly don't know of any nuances between these. While I suspect there may have once been an attempt to separate razor from C#/VB, as you mentioned it doesn't exist today. The whole syntax implementation is a bit wacky, given the whole "copied from pre-CTP 1 Roslyn" nature of it.

Copy link
Member

Choose a reason for hiding this comment

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

Yeah, I just chatted with @chsienki and he didn't know of any reason. It doesn't look to me like anything actually creates SyntaxTrivia instances. That one could probably just be removed.

Copy link
Member

Choose a reason for hiding this comment

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

We're thinking about using SyntaxTrivia if the request for razor preprocessor directives ever goes forward.

Copy link
Contributor

Choose a reason for hiding this comment

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

@davidwengier: It feels like some global usings for common type aliases like these might be useful. What do you think?

No complaints. These type names have always been annoying. Sometimes SyntaxNode is a razor node, sometimes its a roslyn node 🤷‍♂️

@alexgav alexgav enabled auto-merge (squash) August 20, 2024 22:37
@alexgav alexgav merged commit d38698f into main Aug 21, 2024
12 checks passed
@alexgav alexgav deleted the dev/alexgav/MoveFormattingServiceToCommonLayer branch August 21, 2024 01:49
@dotnet-policy-service dotnet-policy-service bot added this to the Next milestone Aug 21, 2024
333fred added a commit to 333fred/razor that referenced this pull request Aug 22, 2024
* upstream/main: (71 commits)
  Fix after merge
  PR feedback
  Bump Roslyn version
  Moving formatting service to common layer (dotnet#10761)
  Move GetSyntaxTree to document snapshot
  Inject file path service into the document snapshot
  Remove code document parameter and just use document snapshot
  Update NOTICE.txt (dotnet#10768)
  Allow @@ as a fallback (dotnet#10752)
  Rework how we get generated documents
  Directly test the component definition service in cohosting
  Add missing test case
  Defer to C# for component attribute GTD in cohosting
  Allow LSP and cohosting to provide specialized methods to get a syntax tree for a C# document
  Dev Container (dotnet#10751)
  Use a proper Try pattern
  Add tests for co-hosted GTD
  Rework IDocumentPositionInfoStrategy and use correctly in co-hosted GTD
  Add DocumentMappingSerice to RazorDocumentServiceBase
  Move IDocumentPositionInfoStrategy and friends to Workspaces layer
  ...
@dibarbet dibarbet modified the milestones: Next, 17.12 P2 Aug 26, 2024
@@ -72,7 +77,7 @@ private IEnumerable<TextEdit> FormatRazor(FormattingContext context, RazorSyntax
{
// Disclaimer: CSharpCodeBlockSyntax is used a _lot_ in razor so these methods are probably
// being overly careful to only try to format syntax forms they care about.
TryFormatCSharpBlockStructure(context, edits, source, node);
TryFormatCSharpBlockStructure(context, edits, source, node); // TODO
Copy link
Contributor

Choose a reason for hiding this comment

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

What is this TODO for?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

My bad, that should've been deleted. It was added when I was passing in hardcoded value for "bracesOnNextLine" options. I ended up not passing it in the parameter list for this method, but forgot to remove TODO. Happy to remove it unless you are editing that file as a part of PR, in which case I'd appreciate if you removed it.

Copy link
Contributor

Choose a reason for hiding this comment

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

Done

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