Lint bit width by alv-around · Pull Request #16902 · rust-lang/rust-clippy

alv-around · 2026-04-22T21:45:19Z

Current state:

suggests change of Uint::BITS - x.leading_zeros() to x.bit_width()
suggests change of Int::BITS - x.leading_zeros() to x.cast_unsigned().bit_width()
suggests change of NonZero::<Uint>::BITS - x.leading_zeros() to x.bit_width().get()
suggests change of NonZero::<Int>::BITS - x.leading_zeros() to x.cast_unsigned().bit_width().get()
when the calling Type of T::BITS does not align with value (x) calling leading_zeros() the lint will raise this mismatch and suggest to replace the whole line with x.bit_width()

Description

rust 1.97 introduces the method bit_width() for uints and NonZero (docs), this will make the manual computation redundant and unnecessary.

Example 1

let x: u32 = b'101';
let bit_width = u32::BITS - x.leading_zeros();

Can be replaced with:

let x: u32 = b'101';
let bit_width = x.bit_width();

Example 2

let y = NonZero::<u32>::new(5).unwrap();
let _ = NonZero::<u32>::BITS - y.leading_zeros();

Can be replaced with:

let y = NonZero::<u32>::new(5).unwrap();
let bit_width = y.bit_width().get();

Example 3

let y: i32 = 5;
let _ = i32::BITS - y.leading_zeros();

Can be replaced with:

let y: i32 = 5;
let _ = y.cast_unsigned().bit_width();

Example 4

let y = NonZero::<i32>::new(5).unwrap();
let _ = NonZero::<i32>::BITS - y.leading_zeros();

Can be replaced with:

let y = NonZero::<i32>::new(5).unwrap();
let bit_width = y.cast_unsigned().bit_width().get();

Example 5

let y: u32 = 5;
let _ = NonZero::<u64>::BITS - y.leading_zeros();

Can be replaced with:

let y: u32 = 5;
let bit_width = y.bit_width();

changelog: [manual_bit_width], [mismatched_bit_width_type]: Added a lint to detect bit_width implementations.

I have

Followed [lint naming conventions][lint_naming]
Added passing UI tests (including committed .stderr file)
cargo test passes locally
Executed cargo dev update_lints
Added lint documentation
Run cargo dev fmt

rustbot · 2026-04-24T07:40:27Z

r? @dswij

rustbot has assigned @dswij.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: 7 candidates
7 candidates expanded to 7 candidates
Random selection from Jarcho, dswij, llogiq

sorairolake · 2026-05-01T01:16:05Z

NonZero::<T>::BITS - x.leading_zeros() returns u32, and x.bit_width() returns NonZero<u32>, where x is NonZero<T>. Therefore, these are not equivalent.

alv-around · 2026-05-04T20:44:59Z

NonZero::<T>::BITS - x.leading_zeros() returns u32, and x.bit_width() returns NonZero<u32>, where x is NonZero<T>. Therefore, these are not equivalent.

Good catch! I remove support NonZero::<T>::BITS - x.leading_zeros() case.

dswij

Sorry for the delay. Overall it looks good, just a small comment and waiting FCP.

@rustbot label lint-nominated

View changes since this review

rustbot · 2026-06-10T06:07:54Z

This lint has been nominated for inclusion.

A FCP topic has been created on Zulip.

ada4a · 2026-06-11T08:31:26Z

NonZero::<T>::BITS - x.leading_zeros() returns u32, and x.bit_width() returns NonZero<u32>, where x is NonZero<T>. Therefore, these are not equivalent.

You could solve this by suggesting x.bit_width().get() when x is a NonZero, no?

ada4a

Very nicely written lint:) Left some small comments

View changes since this review

rustbot · 2026-06-11T10:28:50Z

Reminder, once the PR becomes ready for a review, use @rustbot ready.

alv-around · 2026-06-11T16:52:09Z

NonZero::<T>::BITS - x.leading_zeros() returns u32, and x.bit_width() returns NonZero<u32>, where x is NonZero<T>. Therefore, these are not equivalent.

You could solve this by suggesting x.bit_width().get() when x is a NonZero, no?

@ada4a fair point, I will look into this over the week. In case this make sense I maybe put the changes on a separate PR, on top of this one. What do you think? :)

ada4a · 2026-06-11T17:04:18Z

@ada4a fair point, I will look into this over the week. In case this make sense I maybe put the changes on a separate PR, on top of this one. What do you think? :)

Hm, I'm not fundamentally opposed to the idea – a smaller PR is easier to get merged – but given that the FCP usually takes ~2 weeks anyway, we might as well use the time to bring that new pattern in, as I don't think it's very controversial.

I'd say try implementing the nonzero thing (at your own pace); if you see that that requires a large restructuring of the lint, then consider squashing that change into this PR – because it'd be silly to have a reviewer approve the code just for it to get changed right after; otherwise, feel free to leave it as a separate PR

alv-around · 2026-06-13T20:05:13Z

@ada4a fair point, I will look into this over the week. In case this make sense I maybe put the changes on a separate PR, on top of this one. What do you think? :)

Hm, I'm not fundamentally opposed to the idea – a smaller PR is easier to get merged – but given that the FCP usually takes ~2 weeks anyway, we might as well use the time to bring that new pattern in, as I don't think it's very controversial.

I'd say try implementing the nonzero thing (at your own pace); if you see that that requires a large restructuring of the lint, then consider squashing that change into this PR – because it'd be silly to have a reviewer approve the code just for it to get changed right after; otherwise, feel free to leave it as a separate PR

Ah! I was not aware of the FCP policy, so I went and followed @ada4a feedback and for NonZero the lint suggests bit_width().get(). Let me know if I need to change anything else :)

ada4a

Ok the addition should be pretty uncontroversial I think. One last thing, and that'd be it from my side:)

(EDIT: I've unsubscribed from the thread for now, don't hesitate to ping me if needed)

View changes since this review

ada4a

One last nit, then let's merge:)

View changes since this review

ada4a · 2026-07-04T08:23:08Z

+                let type_invariant = match right_ty.kind() {
+                    // int::BITS or uint::BITS
+                    ty::Uint(_) => IntTypeVariant::UnsignedInt,
+                    ty::Int(_) => IntTypeVariant::SignedInt,
+                    // NonZero::<int/uint>::BITS
+                    ty::Adt(adt, args) if cx.tcx.is_diagnostic_item(sym::NonZero, adt.did()) => {
+                        match args.type_at(0).kind() {
+                            ty::Uint(_) => IntTypeVariant::NonZeroUnsigned,
+                            ty::Int(_) => IntTypeVariant::NonZeroSigned,
+                            _ => return,
+                        }
+                    },
+                    _ => return,
+                };
+
+                if let Some(left_width) = get_bit_width(cx, left_ty)
+                    && let Some(right_width) = get_bit_width(cx, right_ty)
+                    && left_width == right_width
+                {
+                    // manual implementation of bit_width
+                    emit_manual_bit_width(cx, recv, expr, type_invariant);
+                } else {
+                    // mismatched calling types
+                    emit_type_mismatch(cx, recv, expr, type_invariant, right_ty);
+                }
+            },
+            _ => {},
+        }
+    }
+}
+
+fn get_bit_width(cx: &LateContext<'_>, ty: Ty<'_>) -> Option<u64> {
+    // num.bit_width() return None for `usize` and `isize` so we need this wrapper
+    let size_safe_bit_width = |x: Option<u64>| x.or_else(|| Some(cx.tcx.data_layout.pointer_size().bits()));
+
+    match ty.kind() {
+        // int::BITS or uint::BITS
+        ty::Uint(num) => size_safe_bit_width(num.bit_width()),
+        ty::Int(num) => size_safe_bit_width(num.bit_width()),
+        // NonZero::<int/uint>::BITS
+        ty::Adt(adt, args) if cx.tcx.is_diagnostic_item(sym::NonZero, adt.did()) => {
+            let arg = args.type_at(0);
+            match arg.kind() {
+                ty::Uint(num) => size_safe_bit_width(num.bit_width()),
+                ty::Int(num) => size_safe_bit_width(num.bit_width()),
+                _ => None,
+            }
+        },
+        _ => None,
+    }
+}


The duplication is somewhat unfortunate, but oh well..

ada4a

Oh, I actually kind of liked the enum... but this is fine as well.

Could you please squash down the commits? Having multiple commits during development is fine, but since they all amount to iteration over one feature, it's preferable to have the final form to be one commit as well.

View changes since this review

alv-around · 2026-07-06T09:45:22Z

Oh, I actually kind of liked the enum... but this is fine as well.

Could you please squash down the commits? Having multiple commits during development is fine, but since they all amount to iteration over one feature, it's preferable to have the final form to be one commit as well.

View changes since this review

Done :)

ada4a · 2026-07-06T10:13:09Z

Note: I changed the changelog entry to individually bracket each lint name, since that's how you make them valid Markdown links. Ideally, CI would've caught that...

Thank you again for all your work!

ada4a · 2026-07-06T10:22:17Z

Hm, it looks like merging this to latest master causes test failures. Could you please rebase the PR onto master and fix the failures?

rustbot · 2026-07-06T10:46:10Z

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

alv-around · 2026-07-06T10:49:04Z

Note: I changed the changelog entry to individually bracket each lint name, since that's how you make them valid Markdown links. Ideally, CI would've caught that...

Thank you again for all your work!

Ah ok! interesting I updated the change log with cargo bless --test config-metadata as I was suggested..

Thanks for all the amazing feedback and patience :) was so much fun

alv-around · 2026-07-06T11:06:07Z

Hm, it looks like merging this to latest master causes test failures. Could you please rebase the PR onto master and fix the failures?

The failing test happens because the target i686-unknown-linux-gnu is 32 bit. The test was comparing isize with u32 which triggers in 64 bits targets but not for 32. I updated the test to use a u16 so it triggers in 32 and 64 bit targets

ada4a

Thank you very much for sticking with me through this:) One last nit, then let's merge!

View changes since this review

ada4a · 2026-07-07T14:51:09Z

We did it 🎉

rustbot added the needs-fcp PRs that add, remove, or rename lints and need an FCP label Apr 22, 2026

alv-around marked this pull request as ready for review April 24, 2026 07:40

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties label Apr 24, 2026

rustbot assigned dswij Apr 24, 2026

alv-around force-pushed the lint-bit-width branch 2 times, most recently from 8b811db to 236b137 Compare April 24, 2026 08:10

alv-around commented Apr 24, 2026

View reviewed changes

Comment thread clippy_lints/src/manual_bit_width.rs Outdated

alv-around commented Apr 24, 2026

View reviewed changes

Comment thread clippy_lints/src/manual_bit_width.rs Outdated

This comment has been minimized.

Sign in to view

dswij reviewed Jun 10, 2026

View reviewed changes

Comment thread tests/ui/manual_bit_width.rs

rustbot added the lint-nominated Create an FCP-thread on Zulip for this PR label Jun 10, 2026

ada4a requested changes Jun 11, 2026

View reviewed changes

Comment thread clippy_lints/src/manual_bit_width.rs Outdated

Comment thread clippy_lints/src/manual_bit_width.rs Outdated

Comment thread tests/ui/manual_bit_width.rs Outdated

rustbot added S-waiting-on-author Status: This is awaiting some action from the author. (Use `@rustbot ready` to update this status) and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties labels Jun 11, 2026

alv-around force-pushed the lint-bit-width branch from 966cd22 to f2d90b9 Compare June 11, 2026 16:40

This comment has been minimized.

Sign in to view

alv-around requested review from ada4a and dswij June 13, 2026 20:05

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties and removed S-waiting-on-author Status: This is awaiting some action from the author. (Use `@rustbot ready` to update this status) labels Jun 13, 2026

ada4a requested changes Jun 13, 2026

View reviewed changes

Comment thread clippy_lints/src/manual_bit_width.rs Outdated

alv-around requested a review from ada4a June 30, 2026 15:10

ada4a requested changes Jul 4, 2026

View reviewed changes

ada4a approved these changes Jul 5, 2026

View reviewed changes

alv-around force-pushed the lint-bit-width branch from a15d758 to 62ceefb Compare July 5, 2026 21:06

ada4a added this pull request to the merge queue Jul 6, 2026

github-merge-queue Bot removed this pull request from the merge queue due to failed status checks Jul 6, 2026

alv-around force-pushed the lint-bit-width branch from 62ceefb to c2bf51a Compare July 6, 2026 10:46

alv-around force-pushed the lint-bit-width branch from c2bf51a to c5526c9 Compare July 6, 2026 10:59

ada4a reviewed Jul 6, 2026

View reviewed changes

Comment thread tests/ui/mismatched_bit_width_type.rs Outdated

Comment thread tests/ui/manual_bit_width.rs

Comment thread tests/ui/manual_bit_width.rs Outdated

alv-around force-pushed the lint-bit-width branch from c5526c9 to 3f51827 Compare July 6, 2026 11:55

alv-around requested a review from ada4a July 6, 2026 13:18

alv-around force-pushed the lint-bit-width branch 2 times, most recently from af827df to 202fe63 Compare July 7, 2026 12:27

ada4a requested changes Jul 7, 2026

View reviewed changes

Comment thread clippy_lints/src/bit_width.rs

alv-around force-pushed the lint-bit-width branch from 202fe63 to 9cd426c Compare July 7, 2026 14:15

lint manual_bit_width and mismatched_bit_width_type

a35fed2

alv-around force-pushed the lint-bit-width branch from 9cd426c to a35fed2 Compare July 7, 2026 14:22

ada4a approved these changes Jul 7, 2026

View reviewed changes

ada4a added this pull request to the merge queue Jul 7, 2026

Merged via the queue into rust-lang:master with commit 6da9f49 Jul 7, 2026
11 checks passed

This was referenced Jul 7, 2026

Add block_scrutinee lint #16855

Merged

Add new lint: manual_assert_matches #17118

Draft

Uh oh!

Uh oh!

Conversation

alv-around commented Apr 22, 2026 • edited by ada4a Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Example 1

Example 2

Example 3

Example 4

Example 5

Uh oh!

rustbot commented Apr 24, 2026

Uh oh!

Uh oh!

Uh oh!

sorairolake commented May 1, 2026

Uh oh!

alv-around commented May 4, 2026

Uh oh!

This comment has been minimized.

dswij left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

rustbot commented Jun 10, 2026

Uh oh!

ada4a commented Jun 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ada4a left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

rustbot commented Jun 11, 2026

Uh oh!

This comment has been minimized.

alv-around commented Jun 11, 2026

Uh oh!

ada4a commented Jun 11, 2026

Uh oh!

alv-around commented Jun 13, 2026

Uh oh!

ada4a left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

ada4a left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

ada4a Jul 4, 2026

Choose a reason for hiding this comment

Uh oh!

ada4a left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alv-around commented Jul 6, 2026

Uh oh!

ada4a commented Jul 6, 2026

Uh oh!

Uh oh!

ada4a commented Jul 6, 2026

Uh oh!

rustbot commented Jul 6, 2026

Uh oh!

alv-around commented Jul 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

alv-around commented Jul 6, 2026

Uh oh!

Uh oh!

Uh oh!

alv-around commented Apr 22, 2026 •

edited by ada4a

Loading

dswij left a comment •

edited by rustbot

Loading

ada4a commented Jun 11, 2026 •

edited

Loading

ada4a left a comment •

edited by rustbot

Loading

ada4a left a comment •

edited

Loading

ada4a left a comment •

edited by rustbot

Loading

ada4a left a comment •

edited by rustbot

Loading

alv-around commented Jul 6, 2026 •

edited

Loading

ada4a left a comment •

edited by rustbot

Loading