Swiftlint: opening_brace generates false positives on multi-line conditions with inline closures

[robinkunde]

New Issue Checklist

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

Describe the bug

The following code generates a false positive in the opening_brace rule due to the inline closure:

if
    "test".filter({ "0123456789".contains($0) }).isEmpty
{
    // code here
}

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

$ swiftlint lint --no-cache --enable-all-rules opening_brace.swift
Linting Swift files at paths opening_brace.swift
Linting 'opening_brace.swift' (1/1)
/Users/rkunde/opening_brace.swift:3:1: warning: Opening Brace Spacing Violation: Opening braces should be preceded by a single space and on the same line as the declaration. (opening_brace)
Done linting! Found 1 violation, 0 serious in 1 file.

Environment

• SwiftLint version: 0.30.1
• Installation method used: testing both homebrew and cocoapods

• Paste your configuration file: default config (no config file used)

• Are you using nested configurations? no

• Which Xcode version are you using (check xcode-select -p)? 10.1

[marcelofabri]

Not a false positive - it's complaining about the brace in the new line, not the closure one.

534 and #1921 already track similar enhancement requests. @robinkunde, do you think one of these would solve your issue?

[robinkunde]

@marcelofabri Yes, that's the violation I'm talking about. I'm reporting it as a false positive because it if there is no inline closure in the condition, the same warning is not produced. For example, this doesn't produce a warning:

if
    "test".isEmpty
{
    // code here
}

From my reading of the rule's code and nonTriggeringExamples, no warning should be produced in either case.

[marcelofabri]

It seems you're right, sorry for the noise - didn't know we supported this

[craigomac]

We're also affected by this. It only happens when one of the conditions contains a closure.

[stale[bot]]

This issue has been automatically marked as stale because it has not had any recent activity. Please comment to prevent this issue from being closed. Thank you for your contributions!