[Repo Assist] Fix record copy expression indentation when nested in parentheses#3297
Draft
github-actions[bot] wants to merge 1 commit intomainfrom
Draft
Conversation
) Record copy expressions nested inside parentheses could produce F# offside errors after formatting. For example: let b = (({ r with Z = 1; X = "longstring value here" })) would format as: let b = (({ r with Z = 1 <- fields at same column as 'r' -> offside error! X = "longstring value here" })) Root cause: genMultilineRecordCopyExpr uses atCurrentColumnIndent to write the copy-expression identifier, which saves/restores the indentation context. The subsequent indent call then uses the restored (outer binding body) indent level. When nested parens push the identifier to the same column as outer_indent + IndentSize, the fields end up at the same column as the identifier, violating F# indentation rules. Fix: capture the copy-expression column before writing it, then after the normal indent computation, ensure the resulting field indent is strictly greater than the copy-expression column. Use explicit RestoreIndent to cleanly restore the old indent level afterward. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
28 tasks
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
🤖 This PR was created by Repo Assist, an automated AI assistant.
Closes #2529
Root Cause
When formatting a multiline record copy expression (e.g.
{ r with Z = 1; X = "value" }) that is nested inside parentheses, thegenMultilineRecordCopyExprfunction could produce F# offside errors.The issue is in how indentation is computed for the record fields:
atCurrentColumnIndent (genExpr copyExpr)writes the copy-expression identifier (r) at the current column C, temporarily settingIndent = CIndentis restored to the outer binding body level (e.g. 4)indent(IndentBy IndentSize) then computes the field indent as4 + 4 = 8rto column 8 as well,Z = 1lands at the same column asr→ offside errorExample before:
Fix
Capture the column where the copy-expression identifier will be written before calling
atCurrentColumnIndent. After the normalindentcall, if the resultingIndentwould be≤the copy-expression column, bump it tocopyExprColumn + IndentSize. UseRestoreIndent(instead ofunindent/unindent) to cleanly restore the original indent level.Example after:
The fix is backward-compatible: for the common case where the copy expression is not deeply nested,
Indent + IndentSize > copyExprColumnis already true and no adjustment is made.Trade-offs
genMultilineRecordCopyExpris modifiedonlyIf addAdditionalIndent unindent +> unindentwith a singleRestoreIndent oldIndent— equivalent in the common case, but correct when the indent was manually bumpedTest Status
New regression test added in
AlignedMultilineBracketStyleTests.fs:record copy expression nested in parentheses should not produce offside errors