Fix(ish) formatting of RenderFragments (C# templates) #12397
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This means we do a much better, but not perfect, job of formatting render fragments.
This is an unfortunate regression, but IMO the PR still makes for a better overall formatting experience
Contributor
There was a problem hiding this comment.
Pull Request Overview
This PR addresses formatting issues for multi-line RenderFragment expressions in Razor code by improving how the C# formatter generates lambda expressions for these constructs. The key changes involve:
- Adding special handling for multi-line RenderFragments to emit block-bodied lambda expressions instead of null statements
- Tracking whether Roslyn places opening braces on new lines in lambda expressions based on formatting options
- Enhancing the logic to skip opening braces that may be placed on separate lines by Roslyn
Reviewed Changes
Copilot reviewed 3 out of 4 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| HtmlFormattingTest.cs | Updated test expectation to align with improved Caption attribute indentation |
| DocumentFormattingTest.cs | Added semicolons to RenderFragment variable declarations and added 7 new formatting tests covering multi-line RenderFragment scenarios with various brace placement options |
| CSharpFormattingPass.cs | Enhanced brace-skipping logic to check for first non-whitespace character and handle lambda opening braces, with updated comment explaining the behavior |
| CSharpFormattingPass.CSharpDocumentGenerator.cs | Added core logic to detect multi-line RenderFragments, emit lambda expressions instead of null statements, track formatting options for brace placement, and properly close lambda blocks |
src/Razor/src/Microsoft.CodeAnalysis.Razor.Workspaces/Formatting/Passes/CSharpFormattingPass.cs
Outdated
Show resolved
Hide resolved
...eAnalysis.Razor.Workspaces/Formatting/Passes/CSharpFormattingPass.CSharpDocumentGenerator.cs
Outdated
Show resolved
Hide resolved
...eAnalysis.Razor.Workspaces/Formatting/Passes/CSharpFormattingPass.CSharpDocumentGenerator.cs
Outdated
Show resolved
Hide resolved
Co-authored-by: Copilot <[email protected]>
ToddGrun
reviewed
Oct 29, 2025
| formattedCSharpText.Lines[iFormatted + 1] is { Span.Length: > 0 } nextLine && | ||
| nextLine.CharAt(0) == '{') | ||
| nextLine.GetFirstNonWhitespaceOffset() is { } firstNonWhitespace && | ||
| nextLine.Start + firstNonWhitespace == nextLine.End - 1 && |
Contributor
Member
Author
There was a problem hiding this comment.
Yes, good call, thanks. I think I just added this because I noticed it was missing, clearly didn't look far enough down the page :)
This was referenced Oct 30, 2025
This was referenced Nov 1, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #12310
Fixes #6632
This doesn't do a perfect job of formatting these, because there is an extra level of indentation in some (all?) cases, because the Html formatter doesn't see the
@<tag>as a tag. It's a lot better than what we did previously (see screenshot in #12310), and likely needs #11916 for us to be able to do anything better, so I think this is still a net positive for users.