New lint: `decimal_bit_mask` #15215

Artur-Sulej · 2025-07-06T01:09:05Z

Add a new lint that detects the use of decimal literals as bit masks in bitwise operations. Using decimal literals for bit masks can obscure the intended bit pattern and reduce code readability. This lint encourages the use of binary (0b...) or hexadecimal (0x...) notation to make bit patterns explicit and easier to understand at a glance.

Example:

let masked = x & 14; // Bad: decimal literal as bit mask
let masked = x & 0b1110; // Good: bit pattern is explicit

changelog: [decimal_bit_mask]: new lint

Fixes #1775

github-actions · 2025-07-06T01:09:12Z

Lintcheck changes for 35d6cc0

Lint	Added	Removed	Changed
`clippy::decimal_bit_mask`	35	0	0

This comment will be updated if you push new changes

Artur-Sulej · 2025-07-06T01:18:27Z

Although I annotated my test with //~ decimal_bit_mask, Clippy still reports the lint as an unmatched diagnostic and the test fails.
Any idea what I might be missing?

rustbot · 2025-09-03T20:27:46Z

r? @llogiq

rustbot has assigned @llogiq.
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

ada4a · 2025-10-11T15:08:50Z

tests/ui/decimal_bit_mask.rs

+    99 | 0b1010; //~ decimal_bit_mask
+    99 ^ 0b1010; //~ decimal_bit_mask
+    0xD | 99; //~ decimal_bit_mask
+    88 & 99; //~ decimal_bit_mask


Although I annotated my test with //~ decimal_bit_mask, Clippy still reports the lint as an unmatched diagnostic and the test fails.
Any idea what I might be missing?

That's because in this case, you're firing the lint twice, once for each operand, so you'll need to add a second error mark. That's the easiest to do by bringing them to under the linted expression:

Suggested change

88 & 99; //~ decimal_bit_mask

88 & 99;

//~^ decimal_bit_mask

//~| decimal_bit_mask

^ means the lint should happen on the line above the comment

| "attaches" the error mark to another one on a neighbouring line (in this case the //~^ decimal_bit_mask directly above), and will expect a lint at the same location (in this case, the line containing 88 & 99;)

ada4a · 2025-10-11T15:10:05Z

clippy_lints/src/decimal_bit_mask.rs

+            Expr {
+                kind: kind1,
+                span: span1,
+                ..
+            },
+            Expr {
+                kind: kind2,
+                span: span2,
+                ..
+            },
+        ) = &e.kind


It would be a bit more concise to have these simply as left and right, and then use left.span, right.kind etc. throughout the code

ada4a · 2025-10-11T15:11:38Z

clippy_lints/src/decimal_bit_mask.rs

+                span_lint(
+                    cx,
+                    DECIMAL_BIT_MASK,
+                    e.span,


You can improve the output by pointing the lint at the exact operand that is decimal -- for example, here you would use span1 (or left.span, as per previous comment)

ada4a · 2025-10-11T15:13:33Z

clippy_lints/src/decimal_bit_mask.rs

+                    cx,
+                    DECIMAL_BIT_MASK,
+                    e.span,
+                    "Using decimal literal for bit mask. Consider using binary (0b...) or hexadecimal (0x...) notation for better readability.",


The second sentence should be emitted separately, as a help message -- see https://doc.rust-lang.org/clippy/development/emitting_lints.html#emitting-a-lint-1 for more info.

Try using span_lint_and_help here

ada4a · 2025-10-11T15:18:00Z

clippy_lints/src/decimal_bit_mask.rs

+                && let Some(snippet) = snippet_opt(cx, *span2)
+                && !snippet.starts_with("0b")
+                && !snippet.starts_with("0x")


You can use SpanRangeExt::get_source_code here to avoid allocating a String (which is what snippet_opt does)

&& let Some(snippet) = span2.get_source_text(cx)

In fact, since you're only using the snippet to check its contents, you can get away with SpanRangeExt::check_source_code:

Suggested change

&& let Some(snippet) = snippet_opt(cx, *span2)

&& !snippet.starts_with("0b")

&& !snippet.starts_with("0x")

&& span2.check_source_text(cx, |src| !src.starts_with("0b") && !src.starts_with("0x"))

ada4a · 2025-11-06T18:12:33Z

@rustbot note remove Feature-freeze

ada4a · 2025-11-06T18:18:01Z

Could you please change the PR description to something like this?

"""
Add a new lint that detects the use of decimal literals as bit masks in bitwise operations. Using decimal literals for bit masks can obscure the intended bit pattern and reduce code readability. This lint encourages the use of binary (0b...) or hexadecimal (0x...) notation to make bit patterns explicit and easier to understand at a glance.

Example:

let masked = x & 15; // Bad: decimal literal as bit mask
let masked = x & 0b1111; // Good: bit pattern is explicit

changelog: [decimal_bit_mask]: new lint

Fixes #1775
"""

Motivation for the changes:

the changelog message should fit on one line
by using "Fixes", you make it so that when this PR is merged, the corresponding issue is automatically closed

ada4a · 2025-11-06T18:50:51Z

If you look at Lintcheck results (displayed over at #15215 (comment)), you can see a couple of problems with the current implementation:

warning: Using decimal literal for bit mask. Consider using binary (0b...) or hexadecimal (0x...) notation for better readability.
   --> target/lintcheck/sources/sha2-0.11.0-pre.3/src/sha256/x86.rs:100:1
    |
100 | cpufeatures::new!(shani_cpuid, "sha", "sse2", "ssse3", "sse4.1");
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = note: `--force-warn clippy::decimal-bit-mask` implied by `--force-warn clippy::nursery`
    = note: this warning originates in the macro `$crate::__detect_target_features` which comes from the expansion of the macro `cpufeatures::new` (in Nightly builds, run with -Z macro-backtrace for more info)

Here, the lint fires on some binary operation coming deep from an expansion of cpufeatures::new!. Typically, you want to avoid linting things coming from expansion -- please use !e.span.from_expansion() to filter those out. See https://doc.rust-lang.org/clippy/development/macro_expansions.html#the-spanfrom_expansion-method for more information

warning: Using decimal literal for bit mask. Consider using binary (0b...) or hexadecimal (0x...) notation for better readability.
    --> target/lintcheck/sources/chrono-0.4.38/src/naive/date/mod.rs:1344:9
     |
1344 |         self.yof() & (0b1000) == 0
     |         ^^^^^^^^^^^^^^^^^^^^^

Here, 0b1000 isn't recognized as being a binary literal, because the way you check for that is by looking at the span of the literal, but here the span actually contains the parentheses surrounding the literal. Because of that, you'll need to first trim starting paren(s), then possibly some whitespace, and only then performing the actual checks.

warning: Using decimal literal for bit mask. Consider using binary (0b...) or hexadecimal (0x...) notation for better readability.
   --> target/lintcheck/sources/ahash-0.8.11/src/fallback_hash.rs:197:19
    |
197 |         let rot = (self.buffer & 63) as u32;
    |                   ^^^^^^^^^^^^^^^^^^
    |
    = note: `--force-warn clippy::decimal-bit-mask` implied by `--force-warn clippy::nursery`

Here, and in a couple more cases, the decimal operand is a power of 2, or (power of 2 - 1). I think it'd be appropriate to give them a pass. To get the value of a literal, you can go

if let ExprKind::Lit(lit) = left
    && let LitKind::Int(val, _) = lit

with val being your value.

Note that this will also include operands 0 and 1, which is desirable.

warning: Using decimal literal for bit mask. Consider using binary (0b...) or hexadecimal (0x...) notation for better readability.
   --> target/lintcheck/sources/libc-0.2.155/src/unix/linux_like/linux/gnu/b64/x86_64/mod.rs:416:32
    |
416 | pub const O_TMPFILE: ::c_int = 0o20000000 | O_DIRECTORY;
    |                                ^^^^^^^^^^^^^^^^^^^^^^^^

Octal operands probably also make sense in some contexts, so I'd give them a pass as well.

rustbot · 2025-11-12T23:08:54Z

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.

… ignore macro expansion

Artur-Sulej · 2025-11-12T23:50:01Z

@ada4a Thank you for the very thorough review and the clear explanations of all the details! I’ve addressed all the issues, and the PR is ready for another round of review.

Artur-Sulej · 2025-11-13T00:19:00Z

clippy_lints/src/decimal_bit_mask.rs

+}
+
+fn is_not_decimal_number(cx: &LateContext<'_>, span: Span) -> bool {
+    span.check_source_text(cx, |src| src.contains("0b") || src.contains("0x") || src.contains("0o"))


Here, 0b1000 isn't recognized as being a binary literal, because the way you check for that is by looking at the span of the literal, but here the span actually contains the parentheses surrounding the literal. Because of that, you'll need to first trim starting paren(s), then possibly some whitespace, and only then performing the actual checks.

@ada4a I simplified this part (using contains) to handle parentheses, whitespaces and comments. It might miss some complex cases, but that’s an intentional trade-off. Such cases usually mean special constructs and skipping the lint seems more appropriate.

Makes sense! You might want to add a small comment about this (e.g. why you didn't use starts_with)

ada4a

Great progress! Much smaller comments this time (apart from the move-to-operators thing, that might be a bit churny -- sorry about that^^)

View changes since this review

ada4a · 2025-11-14T08:52:14Z

clippy_lints/src/decimal_bit_mask.rs

+}
+
+fn is_not_decimal_number(cx: &LateContext<'_>, span: Span) -> bool {
+    span.check_source_text(cx, |src| src.contains("0b") || src.contains("0x") || src.contains("0o"))


Makes sense! You might want to add a small comment about this (e.g. why you didn't use starts_with)

ada4a · 2025-11-14T08:54:48Z

clippy_lints/src/decimal_bit_mask.rs

+    {
+        for expr in [left, right] {
+            if let ExprKind::Lit(_) = &expr.kind
+                && !is_not_decimal_number(cx, expr.span)


The double negation is a bit confusing. Could you please invert the logic of is_not_decimal_number and rename it accordingly?

ada4a · 2025-11-14T09:02:55Z

clippy_lints/src/decimal_bit_mask.rs

+        for expr in [left, right] {
+            if let ExprKind::Lit(_) = &expr.kind
+                && !is_not_decimal_number(cx, expr.span)
+                && !is_power_of_twoish(expr)
+            {
+                emit_lint(cx, expr.span);


I got really confused here:

Usually, the convention is to call the main expression expr, and subexpressions, if any, e. But you do it the other way around, calling each subexpression (left and right) expr. Because of that, I almost thought you had a logic bug, due to calling is_not_decimal_number and emit_lint on the main expression instead of the subexpression. I'd be grateful if you could swap their names

In this function, you call is_not_decimal_number and emit_lint on expr, while in check_bitwise_assign_expr, you call it on lit. Looking at the test suite (which is very extensive, thanks for that!), one can see the following diagnostics:

error: using decimal literal for bitwise operation --> tests/ui/decimal_bit_mask.rs:18:9 | LL | x ^ (99); | ^^^^ error: using decimal literal for bitwise operation --> tests/ui/decimal_bit_mask.rs:21:11 | LL | x ^= (99); | ^^

So the assign-op case points at the number itself, as the span of lit apparently doesn't include the parens. I think that comes out a bit nicer, so I'd ask you to use lit in this function as well.

Also, as the span the of the literal doesn't include the parens, maybe you might be able use starts_with in is_not_decimal_number after all?

ada4a · 2025-11-14T09:04:30Z

clippy_lints/src/decimal_bit_mask.rs

+        span,
+        "using decimal literal for bitwise operation",
+        None,
+        "use binary (0b...) or hex (0x...) or octal (0o...) notation for better readability",


Suggested change

"use binary (0b...) or hex (0x...) or octal (0o...) notation for better readability",

"use binary (0b...), hex (0x...), or octal (0o...) notation for better readability",

ada4a · 2025-11-14T09:08:15Z

clippy_lints/src/decimal_bit_mask.rs

+    if let ExprKind::AssignOp(
+        Spanned {
+            node: AssignOpKind::BitAndAssign | AssignOpKind::BitOrAssign | AssignOpKind::BitXorAssign,
+            ..
+        },
+        _,
+        expr @ Expr {
+            kind: ExprKind::Lit(lit),
+            ..
+        },
+    ) = &e.kind


very much a nit: imo, these big patterns are too verbose -- what do you think about something like this?

Suggested change

if let ExprKind::AssignOp(

Spanned {

node: AssignOpKind::BitAndAssign | AssignOpKind::BitOrAssign | AssignOpKind::BitXorAssign,

..

},

_,

expr @ Expr {

kind: ExprKind::Lit(lit),

..

},

) = &e.kind

if let ExprKind::AssignOp(op, _, expr) = &e.kind

&& matches!(op.node, AssignOpKind::BitAndAssign | AssignOpKind::BitOrAssign | AssignOpKind::BitXorAssign)

&& let ExprKind::Lit(lit) = expr.kind

ada4a · 2025-11-14T09:11:10Z

clippy_lints/src/decimal_bit_mask.rs

+    ///
+    /// ### Why is this bad?
+    /// Using decimal literals for bit masks can make the code less readable and obscure the intended bit pattern.
+    /// Binary or hexadecimal or octal literals make the bit pattern more explicit and easier to understand at a glance.


Suggested change

/// Binary or hexadecimal or octal literals make the bit pattern more explicit and easier to understand at a glance.

/// Binary, hexadecimal, or octal literals make the bit pattern more explicit and easier to understand at a glance.

ada4a · 2025-11-14T09:11:22Z

clippy_lints/src/decimal_bit_mask.rs

+    #[clippy::version = "1.87.0"]
+    pub DECIMAL_BIT_MASK,
+    nursery,
+    "use binary, hex or octal literals for bitwise operations"


Suggested change

"use binary, hex or octal literals for bitwise operations"

"use binary, hex, or octal literals for bitwise operations"

ada4a · 2025-11-14T09:11:34Z

clippy_lints/src/decimal_bit_mask.rs

+    /// ```rust,no_run
+    /// let a = 0b1110 & 0b0110;
+    /// ```
+    #[clippy::version = "1.87.0"]


This will need to be updated^^

ada4a · 2025-11-14T09:20:19Z

clippy_lints/src/decimal_bit_mask.rs

+    /// let a = 0b1110 & 0b0110;
+    /// ```
+    #[clippy::version = "1.87.0"]
+    pub DECIMAL_BIT_MASK,


Forgot to say this earlier, but lint names should be in plural, see https://rust-lang.github.io/rfcs/0344-conventions-galore.html#lints

ada4a · 2025-11-14T09:22:47Z

clippy_lints/src/decimal_bit_mask.rs

+    "use binary, hex or octal literals for bitwise operations"
+}
+
+declare_lint_pass!(DecimalBitMask => [DECIMAL_BIT_MASK]);


The lint would actually fit quite well into the operators group I think. You can take a look at the lints in the operators/ directory for an example of how to integrate a lint into a group

rustbot · 2025-11-14T14:28:32Z

☔ The latest upstream changes (possibly c48592e) made this pull request unmergeable. Please resolve the merge conflicts.

rustbot added S-blocked Status: marked as blocked ❌ on something else such as an RFC or other implementation work A-lint Area: New lints labels Jul 6, 2025

Artur-Sulej marked this pull request as ready for review September 3, 2025 20:27

rustbot assigned llogiq Sep 3, 2025

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties label Sep 3, 2025

This comment has been minimized.

Sign in to view

Artur-Sulej force-pushed the 1775-decimal_bit_mask branch from 013adec to 12ab9f6 Compare September 15, 2025 12:37

This comment has been minimized.

Sign in to view

Artur-Sulej mentioned this pull request Sep 15, 2025

1775 decimal bit mask Artur-Sulej/rust-clippy#1

Closed

ada4a reviewed Oct 11, 2025

View reviewed changes

samueltardieu added the needs-fcp label Oct 17, 2025

Artur-Sulej force-pushed the 1775-decimal_bit_mask branch from 12ab9f6 to 580fe78 Compare November 6, 2025 15:45

This comment has been minimized.

Sign in to view

rustbot added the has-merge-commits PR has merge commits, merge with caution. label Nov 12, 2025

Artur-Sulej and others added 5 commits November 13, 2025 00:09

New lint: decimal_bit_mask

9dc676c

Add a second error mark for a lint fired twice

0bb3452

Emit help message

f229784

Refactoring: more concise expressions

682106f

Point at the exact operand that fired the lint

5c7ca98

Artur-Sulej added 2 commits November 13, 2025 00:09

Optimization: avoid redundant allocations

2e0b41e

Allow decimal power of 2 and octal literals, literals in parentheses,…

a33e249

… ignore macro expansion

Artur-Sulej force-pushed the 1775-decimal_bit_mask branch from 212fe6e to a33e249 Compare November 12, 2025 23:10

rustbot removed has-merge-commits PR has merge commits, merge with caution. S-waiting-on-author Status: This is awaiting some action from the author. (Use `@rustbot ready` to update this status) labels Nov 12, 2025

Artur-Sulej requested a review from ada4a November 12, 2025 23:50

Use check_source_text for better performance and clarity

4dca87e

Artur-Sulej commented Nov 13, 2025

View reviewed changes

Add test case for bit shift

35d6cc0

ada4a suggested changes Nov 14, 2025

View reviewed changes

-& 99; //~ decimal_bit_mask
+& 99;
+    //~^ decimal_bit_mask
+    //~| decimal_bit_mask

	"use binary (0b...) or hex (0x...) or octal (0o...) notation for better readability",
	"use binary (0b...), hex (0x...), or octal (0o...) notation for better readability",

	/// Binary or hexadecimal or octal literals make the bit pattern more explicit and easier to understand at a glance.
	/// Binary, hexadecimal, or octal literals make the bit pattern more explicit and easier to understand at a glance.

	"use binary, hex or octal literals for bitwise operations"
	"use binary, hex, or octal literals for bitwise operations"

New lint: decimal_bit_mask #15215

Are you sure you want to change the base?

New lint: decimal_bit_mask #15215

Uh oh!

Conversation

Artur-Sulej commented Jul 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions bot commented Jul 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Artur-Sulej commented Jul 6, 2025

Uh oh!

rustbot commented Sep 3, 2025

Uh oh!

This comment has been minimized.

This comment has been minimized.

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

ada4a commented Nov 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ada4a commented Nov 6, 2025

Uh oh!

ada4a commented Nov 6, 2025

Uh oh!

rustbot commented Nov 12, 2025

Uh oh!

This comment has been minimized.

Artur-Sulej commented Nov 12, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rustbot commented Nov 14, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

New lint: `decimal_bit_mask` #15215

New lint: `decimal_bit_mask` #15215

Artur-Sulej commented Jul 6, 2025 •

edited

Loading

github-actions bot commented Jul 6, 2025 •

edited

Loading

ada4a commented Nov 6, 2025 •

edited

Loading

ada4a left a comment •

edited by rustbot

Loading