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

Detect underscored variables with no side effects #7775

Merged
merged 1 commit into from
Oct 20, 2021

Conversation

F3real
Copy link
Contributor

@F3real F3real commented Oct 6, 2021

Fixes #7545

changelog: Lint on underscored variables with no side effects in [no_effect]

@rust-highfive
Copy link

r? @xFrednet

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties label Oct 6, 2021
@flip1995
Copy link
Member

flip1995 commented Oct 6, 2021

This lint should be allowed in all test cases, that don't explicitly test for this lint. Otherwise all the stderr files are just messy.

Please also add a test case, where the assigned value implements Drop, which shouldn't lint, e.g. let _x = vec![1];. This allocates memory and keeps it allocated until the end of the scope, so definitely has an effect.

I'm also not so sure if this should be an extension of the no_effect lint, since it seems pretty noisy. E.g. what happens if the _x variable is used afterwards? A leading _ is no guarantee that the variable is unused. A possible real world example:

let _x = 42; // only required if *one of* f1 or f2 is enabled, 
             // but has to be declared with `_` to avoid warning if none of those features are enabled
let mut y = 0;

// If feature 1 is enabled call foo with `_x - 1`
#[cfg(feature = "f1")]
{ y += foo(_x - 1); }

// If feature 2 is enabled call foo with `_x + 1`
#[cfg(feature = "f2")]
{ y += foo(_x + 1); }

y += foo(0);

@F3real
Copy link
Contributor Author

F3real commented Oct 7, 2021

@flip1995 I had issues with cargo dev bless not being able to update number of tests.

What would be potential issue with Drop? Is this pattern used to prevent dropping value until end of the block. In any case, I will add a test case for it.

Functionality wise, it makes sense to make this part of the no_effect (it is mostly based on existing functionality). But since it does produce large number of reports, maybe we could define new lint in this file to handle it.

I think this makes most sense if used with existing used_underscore_binding lint, since this doesn't detect if binding is used.

@flip1995
Copy link
Member

flip1995 commented Oct 8, 2021

Is this pattern used to prevent dropping value until end of the block

Yes exactly: let _ = vec![]; will drop the vec at the end of the statement. let _x = vec![] will drop the vec at the end of the scope. This is a pretty common pattern, when drop order matters.

Functionality wise, it makes sense to make this part of the no_effect (it is mostly based on existing functionality). But since it does produce large number of reports, maybe we could define new lint in this file to handle it.

Agreed. It's easy to just define another lint and pass it to the span_lint_* function instead of NO_EFFECT. But I'd like input from others, before introducing a new lint for this.

I think this makes most sense if used with existing used_underscore_binding lint, since this doesn't detect if binding is used.

There are two problems with this though.

  1. used_underscore_binding is allow-by-default, while no_effect is warn-by-default
  2. My example from above is not being linted by used_underscore_binding if no feature is enabled. And IIRC if one of the features is being enabled, the lint produces a FP, IIRC: Playground

Copy link
Member

@xFrednet xFrednet left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm also in favor of having this in a new lint, as discussed above, and maybe having it allow-by-default. The logic still looks good, just two NITs and there are still some .stderr with lint triggers where no_effect or the new lint should be allowed in 🙃

clippy_lints/src/no_effect.rs Show resolved Hide resolved
clippy_lints/src/no_effect.rs Outdated Show resolved Hide resolved
tests/ui/no_effect.rs Show resolved Hide resolved
@F3real F3real force-pushed the no_effect branch 3 times, most recently from 74b4b83 to ef24685 Compare October 14, 2021 19:02
Copy link
Member

@xFrednet xFrednet left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Having a new lint for values starting with underscores seems good to me. Thank you for the refactoring 🙃

tests/ui-internal/if_chain_style.stderr Outdated Show resolved Hide resolved
tests/ui/async_yields_async.fixed Outdated Show resolved Hide resolved
clippy_lints/src/no_effect.rs Outdated Show resolved Hide resolved
tests/ui/erasing_op.stderr Outdated Show resolved Hide resolved
tests/ui/eta.stderr Outdated Show resolved Hide resolved
clippy_lints/src/no_effect.rs Outdated Show resolved Hide resolved
clippy_lints/src/no_effect.rs Outdated Show resolved Hide resolved
Copy link
Member

@xFrednet xFrednet left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The implementation part looks good to me. This should be ready for merge once the test output has been added. I also used lintcheck and everything is looking good. You can also squash some commits if you want 🙃

tests/ui/no_effect.rs Show resolved Hide resolved
clippy_lints/src/no_effect.rs Outdated Show resolved Hide resolved
Fix tests after no_effect update

Add a drop testcase

Don't lint _ variables in macro expansion

Address review comments and update tests

Don't shadow unnecessary operation lint if no_effect is allowed

Revert shadowing change and remove no_effect allows

Update clippy_lints/src/no_effect.rs

Co-authored-by: Takayuki Nakata <f.seasons017@gmail.com>

Update clippy_lints/src/no_effect.rs

Co-authored-by: Takayuki Nakata <f.seasons017@gmail.com>

Address review comments
Copy link
Member

@xFrednet xFrednet left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! Thank you for the work and refactoring the code several times! 🙃

@xFrednet
Copy link
Member

@bors r+

@bors
Copy link
Contributor

bors commented Oct 20, 2021

📌 Commit 6b22bba has been approved by xFrednet

@bors
Copy link
Contributor

bors commented Oct 20, 2021

⌛ Testing commit 6b22bba with merge 06722c0...

@bors
Copy link
Contributor

bors commented Oct 20, 2021

☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test
Approved by: xFrednet
Pushing 06722c0 to master...

@bors bors merged commit 06722c0 into rust-lang:master Oct 20, 2021
@F3real F3real deleted the no_effect branch October 20, 2021 10:08
@F3real
Copy link
Contributor Author

F3real commented Oct 20, 2021

@xFrednet np, thanks for reviews 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Detect useless underscored variables with no side effects
6 participants