-
-
Notifications
You must be signed in to change notification settings - Fork 4.4k
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
New: no-useless-return
rule (fixes #7309)
#7441
Conversation
@mysticatea, thanks for your PR! By analyzing the history of the files in this pull request, we identified @IanVS, @vitorbal and @kaicataldo to be potential reviewers. |
LGTM |
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.
Thanks! This mostly looks good, but I have a few questions.
@@ -0,0 +1,83 @@ | |||
# Disallow redundant return statements (no-useless-return) | |||
|
|||
A `return;` statement with nothing after it is redundant, and has no effect on the runtime behavior of a function. This can be confusing, so it's better to disallow these redundant statements |
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.
Oops, I forgot a .
at the end of the sentence: "to disallow these redundant statements**.**"
* @param {ASTNode} node - The return statement node to check. | ||
* @returns {boolean} `true` if the node is removeable. | ||
*/ | ||
function isRemoveable(node) { |
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.
Nit: I think the word is "removable" (no "e" in the middle).
ForOfStatement: markReturnStatementsOnCurrentSegmentsAsUsed, | ||
ForStatement: markReturnStatementsOnCurrentSegmentsAsUsed, | ||
IfStatement: markReturnStatementsOnCurrentSegmentsAsUsed, | ||
ImportDeclaration: markReturnStatementsOnCurrentSegmentsAsUsed, |
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.
Do ImportDeclaration
nodes need to be on this list? I think import
declarations are hoisted, so the following would be redundant:
import {foo} from 'bar';
return;
However, I'm not sure about the correct semantics, because I don't know of any environments with globalReturn: true
that support import
.
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 also don't know such environments 😃 .
In this case, I guessed ImportDeclaration
s behaves as similar to VariableDeclaration
s. On the other hand, even if globalReturn: true
does not support import
, this will not trigger false positive/negative.
LGTM |
LGTM |
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.
LGTM, thanks!
LGTM |
@@ -651,7 +651,7 @@ module.exports = { | |||
if (elements.length > 0 && node.type === "ArrayExpression") { | |||
elements.forEach(el => { | |||
if (el.loc.start.line === node.loc.start.line) { | |||
return; | |||
return; // eslint-disable-line no-useless-return |
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.
Sorry, I'm not sure what the correct fix is.
I tried to change the forEach
to a for-of
statement, but several tests got failing.
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 think we can just remove the entire elements.forEach
block (see #7237 (comment))
LGTM |
OK, ready to merge. |
What is the purpose of this pull request? (put an "X" next to item)
[X] New rule (template)
See #7309 for the template.
What changes did you make? (Give an overview)
This PR implement
no-useless-return
rule.The logic is:
ReturnStatement
nodes which may be useless, it stores the node into both the current code path segment and the current code path.ReturnStatement
nodes from the previous segments.ReturnStatement
, the new segment inheritsReturnStatement
nodes from the unreachable segment. If the unreachable segment was terminated by other kinds of statements, the new segment ignores the unreachable segment. This is the emulation for the case thatReturnStatement
nodes don't exist.ReturnStatement
nodes which are on the current segments from the code path.ReturnStatement
nodes of the code path.In addition, this PR enable
no-useless-return
rule for dogfooding.Is there anything you'd like reviewers to focus on?
no-useless-return
rule seems to conflict tocallback-return
rule. Please check 52f8391. Thought about that?