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

New lint: manual_is_multiple_of #14292

Draft
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

samueltardieu
Copy link
Contributor

@samueltardieu samueltardieu commented Feb 25, 2025

I've added a min_divisor configuration option, default to 4, to not trigger on smaller divisibility operations. I would prefer not to lint if a & 1 == 0 as if a.is_multiple_of(2) by default because the former is very idiomatic in systems (and embedded) programming.

A min_and_mask_size option, defaulting to 3, sets the default bits to be and-masked before this lint triggers; that would be n in v & ((1 << n) - 1) == 0. The form v % 10 == 0 is always linted.

This PR will stay in draft mode until the next rustup which will mark unsigned_is_multiple_of stable for Rust 1.87.0, and the feature flags will be removed.

What should its category be? I've used "complexity", but "pedantic" might be suitable as well.

Close #14289
changelog: [manual_is_multiple_of]: new lint
r? ghost

@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties label Feb 25, 2025
@samueltardieu samueltardieu force-pushed the manual-is-multiple-of branch 3 times, most recently from 5cfb480 to ca4c0a9 Compare February 25, 2025 12:43
@joshtriplett
Copy link
Member

Having a min_divisor configuration option seems reasonable, but I think that option should default to flagging every instance of this. Large codebases that want to keep the & 1 == 0 pattern can set that option.

@samueltardieu
Copy link
Contributor Author

Having a min_divisor configuration option seems reasonable, but I think that option should default to flagging every instance of this. Large codebases that want to keep the & 1 == 0 pattern can set that option.

I've added an extra commit to test this with lintcheck. There was only one hit in Clippy sources (except for tests).

@samueltardieu
Copy link
Contributor Author

@joshtriplett The lintcheck output seems quite reasonable indeed.

@y21
Copy link
Member

y21 commented Feb 25, 2025

I agree with linting the a % b == 0 pattern, but I'm unsure about the & one... Something like (x & 0b111) == 0 feels like a very general expression.
I'm a bit concerned that linting here has the opposite effect: emitting warnings on code that has a totally different semantic meaning where x.is_multiple_of(8) would be a very obfuscated way of checking that the last 3 bits aren't set.

@joshtriplett
Copy link
Member

joshtriplett commented Feb 25, 2025

First of all, please don't treat that as a blocker; it's not as important as the % N == 0 case.

That said: I've seen many, many codebases which use & (PAGE_SIZE - 1) == 0 and similar instead of % PAGE_SIZE == 0, when they know the value is a power of two.

We may need to tune the heuristic to make sure it doesn't produce false positives, and for instance we may want a different threshold for & vs % (& 1 == 0 might be a flag test), but I think things like & 4095 == 0 or & (4096 - 1) == 0 or & (CONST_EQUAL_TO_4096 - 1) == 0 are pretty clear.

Looking at the lintcheck output, I think I agree with not flagging & 1 == 0 by default.

@samueltardieu
Copy link
Contributor Author

What about applying the min-divisor option (maybe using another name, like min-one-bits to represent the number of ones) only to the &(2^n-1) form of the lint, with a sensible default such as 5 bits? The % form would be linted unconditionally.

@joshtriplett
Copy link
Member

joshtriplett commented Feb 25, 2025

@samueltardieu Sounds reasonable. I would say the default should flag 7 and 15 by default, and maybe 3, but not 1. Because 1 might be a flag, but 3 is definitely two bits.

This prevents triggering the new `manual_is_multiple_of` lint on
unrelated lint tests.
@samueltardieu
Copy link
Contributor Author

Done, see the toplevel comment for the updated option.

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.

suggest a.is_multiple_of(b) for a % b == 0
4 participants