False Positive: `default_numeric_fallback` emits warning when the inferred type ends up being the fallback type.

Summary

Summary

When type inferencing infers the type of some numeric literal to be the same as the numeric fallback type (i32 or f64), a warning is incorrectly emitted as though it fell back to being that type. This is especially bad when using macros to write generics over numeric types as you cannot specify the type (at least not in any way that's more ergonomic than adding an allow).

Lint Name

default_numeric_fallback

Reproducer

Reproducer

#![warn(clippy::default_numeric_fallback)]
let a = 92i32;
// will warn on any operation between `a` and a literal, e.g.
let _ = a + 3;
// note `literal << a` and `literal >> a` should warn.

let b = 92f64;
// will warn on any operation between `b` and a literal, e.g.
let _ = b + 3.0;

I expected to see this happen:
No warnings emitted.

Version

rustc 1.94.0 (4a4ef493e 2026-03-02)
binary: rustc
commit-hash: 4a4ef493e3a1488c6e321570238084b38948f6db
commit-date: 2026-03-02
host: x86_64-pc-windows-msvc
release: 1.94.0
LLVM version: 21.1.8

Additional Labels

No response

Locate the implementation and tests for the default_numeric_fallback lint, then run the Rust reproducer from this issue. Verify the behavior for explicitly typed i32 and f64 values in operations with numeric literals, including the noted shift cases; done means no warning when inference already produces the fallback type.