Fix closure_end_indentation corrupting CRLF files#6830
Open
sjh9714 wants to merge 1 commit into
Open
Conversation
The rule computed expected indentation by indexing SourceKitten's file.lines with a line number produced by SwiftSyntax's location converter. The two disagree on CRLF line endings: SwiftSyntax counts \r\n as one newline while StringView splits it into two, inserting a phantom empty line after every real line. On CRLF files the anchor line lookup then hit the wrong (often empty) line, so swiftlint --fix moved closing braces to column 1. Read the anchor line from locationConverter.sourceLines instead, which uses the same line numbering that produced the line number.
Generated by 🚫 Danger |
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
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.
Summary
Fixes #6598.
Running
swiftlint --fixwithclosure_end_indentationon a file with CRLF(
\r\n) line endings moved the closing braces of multi-line closures tocolumn 1, corrupting the file. LF files were unaffected.
The rule computed the expected indentation by indexing SourceKitten's
file.lineswith a line number produced by SwiftSyntax'slocationConverter. The two disagree on CRLF: SwiftSyntax counts\r\nasone newline, while
StringViewsplits it into\nand\rseparately,inserting a phantom empty line after every real line. On CRLF files the
anchor-line lookup therefore hit the wrong (often empty) line, making the
expected indentation column 0.
Changes
ClosureEndIndentationRule.Visitor.getFirstNonWhitespaceColumn(onLine:)now reads the anchor line from
locationConverter.sourceLines, the sameline-numbering domain that produced the line number. No behavior change for
LF files.
triggers, and a genuinely misindented closing brace is corrected to the
right column while CRLF endings are preserved. (
testWrappingInStringisdisabled for the triggering example because the test helper's string
wrapping escapes only
\n, leaving bare\rbytes in the literal.)Testing
swift test --filter ClosureEndIndentationRule— new CRLF test failsbefore the fix (closing braces pulled to column 1) and passes after;
the generated default-examples suite also passes.
swift test— full suite locally (1063 tests), exceptMacroTests, whichcannot run in this environment (no XCTest under Command Line Tools). One
unrelated suite (
UnusedDeclarationRuleGeneratedTests) fails identicallywith and without this change in my environment.
restores the correct indentation; on the correctly indented CRLF file
swiftlint --fixmakes no changes andswiftlintreports 0 violations,with CRLF endings preserved throughout.