Lint bit width

[alv-around]

Fixes #16876

Current state:

• suggests change of T::BITS - x.leading_zeros() for uints
• suggests change of NonZero::<T>::BITS - x.leading_zeros() for NonZero (see comment)

Description

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

Example

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();

changelog: [manual_bit_width]: 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]

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

[alv-around]

Same as in the previous comment

View changes since the review

[sorairolake]

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]

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]

This lint has been nominated for inclusion.

A FCP topic has been created on Zulip.

[ada4a]

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]

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

[rustbot]

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]

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]

@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