Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

opening_brace generates false positives on multi-line conditions with inline closures #2632

Closed
2 tasks done
robinkunde opened this issue Feb 6, 2019 · 8 comments · Fixed by #5164
Closed
2 tasks done
Labels
bug Unexpected and reproducible misbehavior.

Comments

@robinkunde
Copy link
Contributor

New Issue Checklist

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
Copy link
Collaborator

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
Copy link
Contributor Author

robinkunde commented Feb 6, 2019

@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
Copy link
Collaborator

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

@marcelofabri marcelofabri added the bug Unexpected and reproducible misbehavior. label Feb 6, 2019
@craigomac
Copy link

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

@stale
Copy link

stale bot commented Nov 8, 2020

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!

@stale stale bot added the wontfix Issues that became stale and were auto-closed by a bot. label Nov 8, 2020
@stale stale bot closed this as completed Nov 15, 2020
@HiveHicks
Copy link

I have the same problem

@mlorincz
Copy link

Same here, I've got multiple conditions (one of them contains a closure).
No warning if I remove the condition with the closure.

@SimplyDanny SimplyDanny reopened this Aug 27, 2022
@SimplyDanny SimplyDanny removed the wontfix Issues that became stale and were auto-closed by a bot. label Aug 27, 2022
@alex-reilly-pronto
Copy link

I'm also seeing this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Unexpected and reproducible misbehavior.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants