trailing_closure rule disagrees with Swift 5.8 forward-scan matching

[defagos]

New Issue Checklist

• Updated SwiftLint to the latest version
• I searched for existing GitHub issues

Describe the bug

With changes made between SwiftLint 0.54.0 and 0.55.1 the trailing_closure rule now enforces a practice that the Swift compiler considers as deprecated.

Consider a function (or method) whose signature involves several trailing closures with default arguments, like:

func trailingClosures(closure1: () -> Void = {}, closure2: () -> Void = {}) {}

Swift 5.8 introduced changes which lead to a warning being reported when calling the above function as follows:

func someCode() {
    // Xcode warning: "Backward matching of the unlabeled trailing closure is deprecated; label the argument
    // with 'closure2' to suppress this warning"
    trailingClosures {}
}

When fixing the code to silence the Xcode warning:

func someCode() {
    // swiftlint 0.55.1 warning: "Trailing closure syntax should be used whenever possible"
    trailingClosures(closure2: {})
}

SwiftLint 0.55.1 reports a warning. This was not the case with SwiftLint 0.54.0.

Complete output when running SwiftLint, including the stack trace and command used

$ swiftlint lint

Environment

• SwiftLint version (run swiftlint version to be sure)? 0.55.1
• Installation method used (Homebrew, CocoaPods, building from source, etc)? Homebrew / Mint
• Paste your configuration file:

opt_in_rules:
  - trailing_closure

• Are you using nested configurations? No
• Which Xcode version are you using (check xcodebuild -version)? 15.4 (15F31c)
• Do you have a sample that shows the issue?

func trailingClosures(closure1: () -> Void = {}, closure2: () -> Void = {}) {}

func someCode() {
    trailingClosures(closure2: {})
}

[SimplyDanny]

Unfortunately, this is impossible to detect on a syntax-level only. To analyse that correctly, full type information is necessary on the call site about the object that's called. So this is a false positive we have to accept.

[defagos]

Thanks for the feedback. Feel free to close this issue.

[SimplyDanny]

Thanks for the feedback. Feel free to close this issue.

It's still a bug. Maybe one day there's a new way to support this in the tool. Then we may want to revisit all so far "acceptable false positives".