redundant_self_in_closure false positive

[la-pieuvre]

New Issue Checklist

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

Describe the bug

in the typical case where a guard let is used :

guard let lastTimerCallTime else {return}
self.lastTimerCallTime = Date()

affecting a new value to the object property "self.lastTimerCallTime" trigger a false positive and remove the self creating an error since local lastTimerCallTime is immutable

Environment

• SwiftLint version 0.52.2
• Installation method used Homebrew
• Paste your configuration file:

opt_in_rules:
 - redundant_self_in_closure

• Which Xcode version are you using ? 14.3

guard let lastTimerCallTime else {return}
self.lastTimerCallTime = Date()

[SimplyDanny]

This is a known shortcoming of this rule that must generally be accepted, unfortunately. The reason is that normal SwiftLint rules only operate on the Swift AST without knowing anything about types.

The line self.lastTimerCallTime = lastTimerCallTime would be the only special case that is allowed. The rule doesn't trigger on the self. Besides your example there are a bunch of other conceivable cases that cannot easily and especially fast be detected, however.

[la-pieuvre]

Thank you for your fast answer.
What about detecting the value assignment combined with the guard let to prevent the self to be remove?

[SimplyDanny]

Well, it's unimportant where the symbol is defined. You can just have

let x = 1
self.x = 2

to make the rule fail. The point is that there can be a symbol named x anywhere in the outer scopes. Consider for example:

class X {
    var x = 1
    func f(x: Int = 2) {
        var x = 3
        g {
            var x = 4
            self.x = x
        }
    }
    func g(_ work: () -> Void) { work() }
}

This is valid Swift code with 3 reasons why self cannot be left out. Yes, it's possible to track any defined symbols in the same class/struct and trigger the rule only based on this knowledge. This is quite some effort, though.

[SimplyDanny]

I came up with a way to track all identifiers declared up to a certain statement in the code. With that knowledge, the redundant_self_in_closure rule is now able to know better which self. qualification is needed and which isn't.

That is supposed to fix your specific issue and a lot more similar cases.