-
Notifications
You must be signed in to change notification settings - Fork 2.3k
Add opt-in unneeded_throws_rethrows
rule
#6069
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
base: main
Are you sure you want to change the base?
Conversation
Generated by 🚫 Danger |
Source/SwiftLintBuiltInRules/Rules/Lint/UnneededThrowsRule.swift
Outdated
Show resolved
Hide resolved
@SimplyDanny Any thoughts on this? :) |
@tonyskansf It seems that some conflicts have arisen, would you mind resolving them? Thanks! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks very good already! You thought about many special cases already. The rule also makes sense. But adding it as opt-in is important as it can cause false positives in the context of protocol implementations (and maybe more occasions).
I've added a few comments. Please also check the findings reported by the OSS scan.
Source/SwiftLintBuiltInRules/Rules/Lint/UnneededThrowsRule.swift
Outdated
Show resolved
Hide resolved
Source/SwiftLintBuiltInRules/Rules/Lint/UnneededThrowsRule.swift
Outdated
Show resolved
Hide resolved
Source/SwiftLintBuiltInRules/Rules/Lint/UnneededThrowsRule.swift
Outdated
Show resolved
Hide resolved
Source/SwiftLintBuiltInRules/Rules/Lint/UnneededThrowsRule.swift
Outdated
Show resolved
Hide resolved
Source/SwiftLintBuiltInRules/Rules/Lint/UnneededThrowsRuleExamples.swift
Show resolved
Hide resolved
Source/SwiftLintBuiltInRules/Rules/Lint/UnneededThrowsRule.swift
Outdated
Show resolved
Hide resolved
|
||
var children = Set(typeAnnotation.children(viewMode: .sourceAccurate)) | ||
|
||
while let child = children.popFirst() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's dangerous. Consider this example:
let s: S<() throws -> Void> = S()
I think, you should be explicit about the syntax structure to match instead of iterating through all children.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see that for you example it is incorrectly triggering.
be explicit about the syntax structure to match instead of iterating through all children
I'll try to come up with a better solution for these cases
let s: S<() throws -> Void> = S()
let foo: () ↓throws -> Void = {}
Thanks for pointing this out
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please check out 25c4905.
Instead of iterating over all children, this implementation checks the PatternBindingSyntax.typeAnnotation
type for only specific cases - that should be more explicit about which syntax structure we're interested in.
Please let me know if this is better approach or suggest other.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks better. TupleTypeSyntax
is only relevant when the tuple has only one element, isn't it. Otherwise, it's hard to check the necessity of throws
keywords.
Also, we should have test case for the cases in the switch of the types.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's true. The necessity of throws
keywords could depend on a context we don't know.
I'll keep the check for single-element TupleTypeSyntax
only. Making the rule less strict.
I've also added new test cases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please check 84b7081
Source/SwiftLintBuiltInRules/Rules/Lint/UnneededThrowsRule.swift
Outdated
Show resolved
Hide resolved
You need to rebase onto |
3c154d1
to
bb93bfe
Compare
Source/SwiftLintBuiltInRules/Rules/Lint/UnneededThrowsRule.swift
Outdated
Show resolved
Hide resolved
Source/SwiftLintBuiltInRules/Rules/Lint/UnneededThrowsRule.swift
Outdated
Show resolved
Hide resolved
|
||
var children = Set(typeAnnotation.children(viewMode: .sourceAccurate)) | ||
|
||
while let child = children.popFirst() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks better. TupleTypeSyntax
is only relevant when the tuple has only one element, isn't it. Otherwise, it's hard to check the necessity of throws
keywords.
Also, we should have test case for the cases in the switch of the types.
@SimplyDanny Please can you take a look again. Appreciate your time! Thank you |
Add a new opt-in rule that detects unnecessary
throws
, helping avoid misleading definitions and requirements for the caller to write unnecessary error handling.