`eq_op` false positive when statically asserting that a numeric value is equal to a byte literal

[Zalathar]

Summary

I was writing some code where I wanted to reassure readers that a particular numeric value corresponds to a particular ASCII character (e.g. 0x20 == b' ').

I expressed this fact as a compiler-checked static assertion:

const _: () = assert!(0x20 == b' ');

Surprisingly, clippy flags this pattern not just as a warning, but as a hard error by default.

Lint Name

eq_op

Reproducer

I tried this code:

fn main() {
    const _: () = assert!(0x20 == b' ');
}

I saw this happen:

error: equal expressions as operands to `==`
 --> src/main.rs:2:27
  |
2 |     const _: () = assert!(0x20 == b' ');
  |                           ^^^^^^^^^^^^
  |
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#eq_op
  = note: `#[deny(clippy::eq_op)]` on by default

I expected to see this happen:

• No error or warning.

Version

rustc 1.89.0 (29483883e 2025-08-04)
binary: rustc
commit-hash: 29483883eed69d5fb4db01964cdf2af4d86e9cb2
commit-date: 2025-08-04
host: aarch64-apple-darwin
release: 1.89.0
LLVM version: 20.1.7

Additional Labels

No response

[Zalathar]

A similar false-positive can occur when asserting that a literal is equal to a const {} block, or that two const blocks are equal.

If eq_op is error-by-default, perhaps it should be much narrower than it currently is, e.g. only forbidding literals in the same format.

[youknowone]

For me, const { assert!(f64::MAX_10_EXP == 308) }; This is not only false positive. #[allow(clippy::eq_op)] is also useless. #[allow(clippy::correctness)] does work