JS: Ignore returned exprs in defensive programming query #3627
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
asgerf
added
JS
Awaiting evaluation
This was
linked to
issues
Jun 5, 2020
|
LGTM. |
asgerf
force-pushed
the
js/unneeded-defensive-return
branch
2 times, most recently
from
3d14c8b to
6750cf7
Compare
erik-krogh
previously approved these changes
Jun 22, 2020
asgerf
force-pushed
the
js/unneeded-defensive-return
branch
from
6750cf7 to
a109c1f
Compare
|
The initial evaluation looked bad. Apart from the performance (possibly noise), we lost two TPs due to ignoring returned expressions. I've reverted the change to returned expressions and left in the special-cased check for |
erik-krogh
approved these changes
Jun 25, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The unneeded defensive code query would sometimes flag the return value of a function as being a defensive code pattern, which doesn't seem like it qualifies as a defensive code pattern.
This "fixes" #3626 although in a somewhat indirect way.