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

Duplicate Key in Dictionary Literal with Computed Var #5077

Open
2 tasks done
aetherealtech opened this issue Jun 23, 2023 · 1 comment
Open
2 tasks done

Duplicate Key in Dictionary Literal with Computed Var #5077

aetherealtech opened this issue Jun 23, 2023 · 1 comment
Labels
acceptable-false-positive False positives caused by rules that are unavoidable due to missing type information. bug Unexpected and reproducible misbehavior.

Comments

@aetherealtech
Copy link

New Issue Checklist

Describe the bug

The duplicated_key_in_dictionary_literal warning is triggered when one static computed var is used repeatedly in a dictionary literal, despite the var being computed and therefore not necessarily the same on every read.

Complete output when running SwiftLint, including the stack trace and command used
$ swiftlint lint
warning: Duplicated Key in Dictionary Literal Violation: Dictionary literals with duplicated keys will crash at runtime (duplicated_key_in_dictionary_literal)

Environment

  • SwiftLint version: 0.52.3
  • Installation method used: Homebrew
  • Paste your configuration file: N/A (default config)
// This triggers a violation:
var currentValue = 0
var generateNewValue: Int {
    let current = currentValue
    currentValue += 1
    return current
}

let testDict = [
    generateNewValue: "",
    generateNewValue: "",
    generateNewValue: "",
]
@SimplyDanny
Copy link
Collaborator

SwiftLint's normal rules operate on syntax-level only. Therefore, they don't know if generateNewValue is a constant or a computed property. Even with this information, it's unclear if computing the property has any side-effects, especially when the property is defined in another type that might even be imported from another module.

That said, the rule accepts function calls assuming they always produce a different value. It has to make compromises and UUID() was a good reason to exclude function calls.

Long story short, while this is a bug I think we have to accept the false-positives caused by code similar to yours.

@SimplyDanny SimplyDanny added bug Unexpected and reproducible misbehavior. acceptable-false-positive False positives caused by rules that are unavoidable due to missing type information. labels Jun 24, 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