[0.55.1] False positive on `unused_element` where element and index are used separately in subsequent blocks

[michaeleustace]

New Issue Checklist

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

Describe the bug

The rule should not trigger when the enumerated index and element are used in separate subsequent blocks

Environment

• SwiftLint version (run swiftlint version to be sure)? 0.55.1
• Installation method used (Homebrew, CocoaPods, building from source, etc)? Cocoapods
• Paste your configuration file:

# insert yaml contents here

• Are you using nested configurations? No If so, paste their relative paths and respective contents.
• Which Xcode version are you using (check xcodebuild -version)? 15.3
• Do you have a sample that shows the issue? Run echo "[string here]" | swiftlint lint --no-cache --use-stdin --enable-all-rules to quickly test if your example is really demonstrating the issue. If your example is more complex, you can use swiftlint lint --path [file here] --no-cache --enable-all-rules.

protocol Rule {
  func isValid() -> Bool
}

let rules: [Rule] = [rule1, rule2]
let messages = ["msg1", "msg2"]

// This triggers a violation:
rules.enumerated()
    .first { $0.element.isValid() == false }
    .flatMap { messages[$0.offset] }

[mildm8nnered]

So unfortunately we do only cover the first block - I couldn't find a good way to keep track of the variables through subsequent blocks - see #5498 for discussion. There were no examples of subsequent block usage in the open source projects that SwiftLint gets tested against, so we hoped that this would not affect many people.

If that particular idiom is common in your codebase, you could disable the rule locally, or in your configuration.

[SimplyDanny]

While the advice the rule is providing might be misleading in this case, it still highlights an issue in the code. Because it could indeed be rewritten entirely without the .enumerated() as:

rules.firstIndex { !$0.isValid() }.flatMap { messages[$0] }