SwiftLint icon indicating copy to clipboard operation
SwiftLint copied to clipboard

optional_enum_case_matching triggers on non-enum switch

Open vokal-isaac opened this issue 5 years ago • 11 comments

New Issue Checklist

Describe the bug

The optional_enum_case_matching rule is triggered when switching over an optional struct with cases that are static members of the struct. In these instances, removing the ? on the case results in code that doesn't compile (Xcode 11.1).

Complete output when running SwiftLint, including the stack trace and command used
$ swiftlint lint --use-stdin --enable-all-rules
/// Test struct
public struct Foo: Equatable {
    public static let bar: Foo = .init(foo: "bar")

    public let foo: String
}

/// Test variable
public var something: Foo?

switch something {
case .bar?:
    print("bar")

default:
    print("default")
}
<nopath>:12:10: warning: Optional Enum Case Match Violation: Matching an enum case against an optional enum without '?' is supported on Swift 5.1 and above.  (optional_enum_case_matching)
Done linting! Found 1 violation, 0 serious in 1 file.

Environment

  • SwiftLint version (run swiftlint version to be sure)?
    0.38.2
  • Installation method used (Homebrew, CocoaPods, building from source, etc)?
    CocoaPods
  • Paste your configuration file
    n/a
  • Are you using nested configurations? If so, paste their relative paths and respective contents.
    n/a
  • Which Xcode version are you using (check xcodebuild -version)?
    Xcode 11.1, Build version 11A1027
  • 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.
    see above

vokal-isaac avatar Jan 16 '20 18:01 vokal-isaac

I'm having the same issue.

Looks like this is the place to add such rule https://github.com/realm/SwiftLint/blob/master/Source/SwiftLintFramework/Rules/Style/OptionalEnumCaseMatchingRule.swift#L185 but I couldn't figure out a way to identify the type of the identifier after a quick glance.

Any help from a more avid SwiftLint contributor? :)

rogerluan avatar Jun 03 '20 17:06 rogerluan

@marcelofabri could you shed some light here? 😊

rogerluan avatar Jun 03 '20 20:06 rogerluan

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[bot] avatar Nov 08 '20 03:11 stale[bot]

This is still a problem! I faced this problem again last week

rogerluan avatar Nov 08 '20 14:11 rogerluan

If you'd like to try fixing this yourself, the steps in CONTRIBUTING.md should be a good start and you can ask questions here if you get stuck.

jpsim avatar Nov 08 '20 14:11 jpsim

@jpsim I couldn't figure out how to determine the type of the identifier (e.g. distinguish between enum and struct, or enum and a class). Not sure if this is possible in SwiftLint either, given that we use regex for most (all?) of the parsing. Could you shed some light? 😊

rogerluan avatar Nov 08 '20 14:11 rogerluan

Look for uses of SwiftDeclarationKind.enum in the codebase, there are lots of examples. Here's one example: https://github.com/realm/SwiftLint/blob/67165f7c642179a849632f962f584ea728137dfc/Source/SwiftLintFramework/Rules/Idiomatic/ExplicitEnumRawValueRule.swift#L77

jpsim avatar Nov 08 '20 14:11 jpsim

Thanks!! I'll look into this 😃

rogerluan avatar Nov 08 '20 16:11 rogerluan

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[bot] avatar Jan 07 '21 16:01 stale[bot]

Please don't close this, bot.

rogerluan avatar Jan 08 '21 01:01 rogerluan

The existing rule is unable to know the type of the identifier in the switch condition. This knowledge is only available in a type-checked AST that would be available in an Analyzer rule.

So basically a new rule would need to be introduced to handle this case properly. I'll mark this issue as a "rule request" therefore.

SimplyDanny avatar Sep 10 '22 21:09 SimplyDanny