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

I have trailing_closure where is not #5150

Open
hrvoje0099 opened this issue Jul 31, 2023 · 5 comments
Open

I have trailing_closure where is not #5150

hrvoje0099 opened this issue Jul 31, 2023 · 5 comments
Labels
acceptable-false-positive False positives caused by rules that are unavoidable due to missing type information. bug Unexpected and reproducible misbehavior.

Comments

@hrvoje0099
Copy link

New Issue Checklist

Describe the bug

image
image

The code has no closure as an argument, so the trailing closure syntax cannot be applied.

Complete output when running SwiftLint, including the stack trace and command used
Linting Swift files in current working directory
Linting 'validate_words.swift' (1/1)
/Users/vukovihr/Desktop/test_skript/validate_words.swift:14:12: warning: Operator Function Whitespace Violation: Operators should be surrounded by a single whitespace when defining them (operator_whitespace)
/Users/vukovihr/Desktop/test_skript/validate_words.swift:8:1: warning: Trailing Whitespace Violation: Lines should not have trailing whitespace (trailing_whitespace)
/Users/vukovihr/Desktop/test_skript/validate_words.swift:48:1: warning: Trailing Whitespace Violation: Lines should not have trailing whitespace (trailing_whitespace)
/Users/vukovihr/Desktop/test_skript/validate_words.swift:51:1: warning: Trailing Whitespace Violation: Lines should not have trailing whitespace (trailing_whitespace)
/Users/vukovihr/Desktop/test_skript/validate_words.swift:54:1: warning: Trailing Whitespace Violation: Lines should not have trailing whitespace (trailing_whitespace)
Done linting! Found 5 violations, 0 serious in 1 file.

Environment

  • SwiftLint version (run swiftlint version to be sure)? 👉 0.52.4
  • Installation method used (Homebrew, CocoaPods, building from source, etc)? 👉 Homebrew
  • Which Xcode version are you using (check xcodebuild -version)? 👇
Xcode 14.3.1
Build version 14E300c
@SimplyDanny
Copy link
Collaborator

The rule complains about the closure argument of the handleEvents method but triggers always at the very beginning of the chain.

The rule, therefore, is correct but the trigger location should be improved to be the method with the closure argument itself.

@SimplyDanny SimplyDanny added the bug Unexpected and reproducible misbehavior. label Aug 1, 2023
@hrvoje0099
Copy link
Author

But receiveOutput is not the last argument in the handleEvents method, what can I do there? What can I do to make the warning disappear? Thank you

@SimplyDanny
Copy link
Collaborator

How is handleEvents defined?

@hrvoje0099
Copy link
Author

hrvoje0099 commented Aug 2, 2023

func handleEvents(receiveSubscription: ((Subscription) -> Void)? = nil, receiveOutput: ((Self.Output) -> Void)? = nil, receiveCompletion: ((Subscribers.Completion<Self.Failure>) -> Void)? = nil, receiveCancel: (() -> Void)? = nil, receiveRequest: ((Subscribers.Demand) -> Void)? = nil) -> Publishers.HandleEvents<Self>

https://developer.apple.com/documentation/combine/anypublisher/handleevents(receivesubscription:receiveoutput:receivecompletion:receivecancel:receiverequest:)

@SimplyDanny
Copy link
Collaborator

In this case, it's really a bug in the rule. Using a trailing closure would not compile or lead to semantical changes which is not okay. However, since this rule operators on syntax-level without type information and, in your case, function signature information only, it cannot do better. We have to live with such false positives if the rule shall at the same time be very fast, unfortunately.

SwiftLint also offers so called "Analyzer Rules" which have a deeper knowledge about types and exact signatures. They are very slow and a separate SwiftLint run is required, on the other hand.

@SimplyDanny SimplyDanny added the acceptable-false-positive False positives caused by rules that are unavoidable due to missing type information. label Aug 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
acceptable-false-positive False positives caused by rules that are unavoidable due to missing type information. bug Unexpected and reproducible misbehavior.
Projects
None yet
Development

No branches or pull requests

2 participants