Autocorrect for redundant_void_return can cause code breakage

[mikaryyn]

New Issue Checklist

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

Describe the bug

After upgrading to SwiftLint to 0.55.1 code like this (below) breaks when applying --fix. Reverting to version 0.53.0 makes it work. I found some easy workarounds but I don't think it's good to break existing code.

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

main.swift

func takesClosure(_ closure: () -> Void) { }

@discardableResult func returnsInt() -> Int { 42 }

let testClosure = { () -> Void in returnsInt() }

takesClosure(testClosure)

This code works but after swiftlint --fix, swift main.swift causes error:

main.swift:7:14: error: cannot convert value of type '() -> Int' to expected argument type '() -> Void'

Environment

• SwiftLint version (run swiftlint version to be sure)? 0.55.1.

• Installation method used (Homebrew, CocoaPods, building from source, etc)? Homebrew.

• Paste your configuration file: n/a.

• Are you using nested configurations? No.

• Which Xcode version are you using (check xcodebuild -version)? 15.4.

• Do you have a sample that shows the issue? Yes, above.

[vadimvitvickiy]

Having the same issue.

[SimplyDanny]

As SwiftLint works on the syntax level only, it cannot behave entirely correct here. Due to implicit returns, the statement is ambiguous here. Without full type information for the function, it's impossible to resolve the ambivalence.

There are three ways to "fix" this that come into my mind. They all come with their own drawbacks:

1. Ignore closures with just a single statement. This would suddenly silence a lot of valid findings from then on as well.
2. The rule has the option include_closures which can be set to false to exclude closure signatures entirely if there are too many false positives.
3. An explicit // swiftlint:disable command can be used.

From all these, I would actually prefer and recommend the last one as we cannot achieve full correctness in any way.