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

SwiftLint Incorrectly Flags @Parameter Type Annotation as Redundant in TipKit Integration #5366

Closed
2 tasks done
thanhdolong opened this issue Nov 24, 2023 · 5 comments · Fixed by #5389
Closed
2 tasks done
Assignees
Labels
bug Unexpected and reproducible misbehavior. good first issue Issue to be taken up by new contributors yet unfamiliar with the project.

Comments

@thanhdolong
Copy link

New Issue Checklist

Describe the bug

While integrating TipKit, as documented here, a conflict arises with SwiftLint's handling of redundant type annotations. Specifically, SwiftLint incorrectly flags the type annotation in the @parameter attribute as redundant, which, when auto-corrected, leads to a compilation failure.

Complete output when running SwiftLint, including the stack trace and command used
$ swiftlint lint
# Output indicating 'redundant_type_annotation' violation for the @Parameter attribute

Environment

  • SwiftLint version 0.53.0
  • Installation method used CocoaPods
  • Xcode 15.0.1 - Build version 15A507
// This triggers a violation:
@Parameter
static var isLoggedIn: Bool = false

image
image

Additional Context

SwiftLint's redundant_type_annotation rule suggests the removal of the for type annotation in the @Parameter attribute, which, if applied, results in a compilation error. A temporary workaround is to disable this specific rule using // swiftlint:disable redundant_type_annotation for the affected line. Are there any better solutions to keep this rule and support macros?

@SimplyDanny SimplyDanny added bug Unexpected and reproducible misbehavior. discussion Topics that cannot be categorized as bugs or enhancements yet. They require further discussions. labels Nov 24, 2023
@SimplyDanny
Copy link
Collaborator

SimplyDanny commented Nov 24, 2023

Four options:

  1. Disable the rule for all declarations with attributes.
  2. Ignore declarations annotated with @Parameter.
  3. Make the attributes to ignore configurable.
  4. Accept that // swiftlint:disable has to be used sometimes.

I tend towards the third option. More and more attributes are being added to the language, there are property wrappers and now also macros. It's impossible to know which data these attributes require to work. Users know and so they should be able to configure them for exclusion.

@thanhdolong
Copy link
Author

Hi @SimplyDanny

Thanks for your quick response! I’m keen on making attributes configurable for SwiftLint as you suggested. Could you share more details or best practices on how to implement this? Your guidance would be really helpful.

@SimplyDanny
Copy link
Collaborator

Appreciate your readiness!

The rule is called RedundantTypeAnnotationRule in Swift. It currently only has the most basic configuration to set the rule's severity level. So it needs its own specific configuration first. Many other rules already have their own. Just check out a few to find their associated configuration. You'll see that these configurations are rather easy structured. Then you need to respect the configuration in the rule's implementation. I suspect that the method isIBInspectable is a good place to start as it already checks for the @IBInspectable attribute.

Have fun!

PS: In case you are highly motivated, you may even consider rewriting the whole rule using SwiftSyntax. This is a long-term goal of this project. There are not that many rules left to be rewritten but RedundantTypeAnnotationRule is one of them. You can find a lot of example for these rewrites by looking for commits that read "Rewrite <rule_id> rule with SwiftSyntax". This is independent of this ticket, though, and can be done separately first or thereafter.

@SimplyDanny SimplyDanny added good first issue Issue to be taken up by new contributors yet unfamiliar with the project. and removed discussion Topics that cannot be categorized as bugs or enhancements yet. They require further discussions. labels Dec 2, 2023
@tonell-m
Copy link
Contributor

tonell-m commented Dec 8, 2023

Hey, I'm willing to work on this 🙂

@SimplyDanny
Copy link
Collaborator

@tonell-m: Great! Please go ahead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Unexpected and reproducible misbehavior. good first issue Issue to be taken up by new contributors yet unfamiliar with the project.
Projects
None yet
3 participants