swiftlint --fix is ignoring // swiftlint:disable:this closure_end_indentation

[tomaskraina]

trafficstars

New Issue Checklist

• [x] I've Updated SwiftLint to the latest version.
• [x] I've searched for existing GitHub issues.

Bug Description

A clear and concise description of what the bug is. Ideally, provide a small (but compilable) example code snippet that can be used to reproduce the issue.

// This triggers a violation:
        let strings: [String] = [
            "a",
            "b"
        ].compactMap {
            $0 == "a" ? $0 : nil
            }

// This does not trigger a violation (correctly):
        let strings: [String] = [
            "a",
            "b"
        ].compactMap {
            $0 == "a" ? $0 : nil
            } // swiftlint:disable:this closure_end_indentation

Now, running $ swiftlint lint --fix seems to ignore the closure_end_indentation inline rule:

tomkraina@MBP Swiftlint % swiftlint lint --fix swiftlint-issue.swift 
Correcting Swift files at paths swiftlint-issue.swift
Correcting 'swiftlint-issue..swift' (1/1)
swiftlint-issue.swift: Corrected closure_end_indentation 1 time
Done correcting 1 file!

// This gets however incorrectly fixed to this:
        let strings: [String] = [
            "a",
            "b"
        ].compactMap {
            $0 == "a" ? $0 : nil
         } // swiftlint:disable:this closure_end_indentation

Environment

• SwiftLint version (run swiftlint version to be sure): 0.59.1
• Xcode version (run xcodebuild -version to be sure): Xcode 16.4 Build version 16F6
• Installation method used (Homebrew, CocoaPods, building from source, etc): brew install swiftlint
• Configuration file:

opt_in_rules:
  - closure_end_indentation

Are you using nested configurations? If so, paste their relative paths and respective contents.

[SimplyDanny]

I can see that it is fixed even though the comment is supposed to prohibit it. However, the fix that is applied looks correct per se. I can't reproduce the wrong indentation.

[tomaskraina]

I can see that it is fixed even though the comment is supposed to prohibit it. However, the fix that is applied looks correct per se. I can't reproduce the wrong indentation.

Yes, the fix is correct. I should have provided a better example :) There's a number of cases where the closure_end_indentation rule produces false positives. That's what I'm hitting in my code (not demonstrated by the example above). See e.g. https://github.com/realm/SwiftLint/issues/3704

So my problem is really a combination of these two issues related to closure_end_indentation:

• reporting false positives (can be suppressed by the comment // swiftlint:disable:this closure_end_indentation)
• swiftlint lint --fix is ignoring the suppressing comment

Let's take an example from the issue linked above:

Observable.combineLatest(
    mapSectionProviders(context: context)
        .map { provider -> Observable<HomeSection> in
            provider.fetch(context: context)
                .startWith(.empty)
                .catchAndReturn(.empty)
        }
).map { sections in
    sections.filter { !$0.items.isEmpty }
}

running swiftlint lint --fix will format the code to this (notice the last trailing closure):

Observable.combineLatest(
    mapSectionProviders(context: context)
        .map { provider -> Observable<HomeSection> in
            provider.fetch(context: context)
                .startWith(.empty)
                .catchAndReturn(.empty)
        }
).map { sections in
    sections.filter { !$0.items.isEmpty }
                }

and using // swiftlint:disable:this closure_end_indentation is no help here; running swiftlint lint --fix will result in this:

Observable.combineLatest(
    mapSectionProviders(context: context)
        .map { provider -> Observable<HomeSection> in
            provider.fetch(context: context)
                .startWith(.empty)
                .catchAndReturn(.empty)
        }
).map { sections in
    sections.filter { !$0.items.isEmpty }
                } // swiftlint:disable:this closure_end_indentation

[SimplyDanny]

Thanks for the clarification, @tomaskraina! The issue has meanwhile been resolved by #6109.