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

Skip if_not_else lint for '!= 0'-style checks #11028

Merged
merged 1 commit into from Oct 23, 2023

Conversation

BenWiederhake
Copy link
Contributor

Currently, clippy makes unhelpful suggestions such as this:

warning: unnecessary `!=` operation
   --> src/vm.rs:598:36
    |
598 |                     *destination = if source & 0x8000 != 0 { 0xFFFF } else { 0 };
    |                                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = help: change to `==` and swap the blocks of the `if`/`else`
    = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#if_not_else
    = note: `-W clippy::if-not-else` implied by `-W clippy::pedantic`

Bit tests often take on the form if foo & 0x1234 != 0 { … } else { … }, and the != 0 part reads as "has any bits set". Therefore, this code already has the "correct" order, and shouldn't be changed.

This PR disables the lint for these cases, and in fact all cases where the condition is "foo is non-zero".

I did my homework:

  • Followed [lint naming conventions][lint_naming] → Not applicable, this PR fixes an existing lint
  • Added passing UI tests (including committed .stderr file) → Yes, tests/ui/if_not_else_bittest.rs
  • cargo test passes locally
  • Executed cargo dev update_lints
  • Added lint documentation → Not applicable, this PR fixes an existing lint
  • Run cargo dev fmt

changelog: Fix [if_not_else] false positive when something like bitflags != 0 is used

@rustbot
Copy link
Collaborator

rustbot commented Jun 25, 2023

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @llogiq (or someone else) soon.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

  • @rustbot author: the review is finished, PR author should check the comments and take action accordingly
  • @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties label Jun 25, 2023
@llogiq
Copy link
Contributor

llogiq commented Oct 23, 2023

Ok, this seems like it should reduce the less useful messages from clippy, so thank you!

@bors r+

@bors
Copy link
Collaborator

bors commented Oct 23, 2023

📌 Commit 5e17f9f has been approved by llogiq

It is now in the queue for this repository.

@bors
Copy link
Collaborator

bors commented Oct 23, 2023

⌛ Testing commit 5e17f9f with merge f942470...

@bors
Copy link
Collaborator

bors commented Oct 23, 2023

☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test
Approved by: llogiq
Pushing f942470 to master...

@bors bors merged commit f942470 into rust-lang:master Oct 23, 2023
5 checks passed
@BenWiederhake BenWiederhake deleted the dev-ifnotelse_neqzero branch October 23, 2023 09:03
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.

None yet

4 participants