Summary
The suboptimal_flops lint fails to suggest mul_add when an intermediate variable is used, but only if that variable was initialised using a numeric literal without an explicit type suffix or annotation. If the literal is replaced by a named constant, an explicit type suffix (0.1_f32), or a type annotation on the variable, the lint correctly triggers.
Lint Name
suboptimal_flops
Reproducer
I tried this code:
#[must_use]
pub fn missed_opportunity(k: f32) -> f32 {
let k3 = k * k * k;
let y = k3 + 0.1; // The "naked" literal 0.1 poisons the tracking of y
1.0 - y * 0.3 // No lint triggered
}
#[must_use]
pub fn correctly_identified_with_suffix(k: f32) -> f32 {
let k3 = k * k * k;
let y = k3 + 0.1_f32; // Explicit suffix fixes it
1.0 - y * 0.3 // Flags: suggests y.mul_add(-0.3, 1.0)
}
#[must_use]
pub fn correctly_identified_with_annotation(k: f32) -> f32 {
let k3 = k * k * k;
let y: f32 = k3 + 0.1; // Explicit type annotation fixes it
1.0 - y * 0.3 // Flags: suggests y.mul_add(-0.3, 1.0)
}
#[must_use]
pub fn correctly_identified_with_const(k: f32) -> f32 {
const OFFSET: f32 = 0.1;
let k3 = k * k * k;
let y = k3 + OFFSET; // Named constant fixes it
1.0 - y * 0.3 // Flags: suggests y.mul_add(-0.3, 1.0)
}
I expected to see this happen:
In all four cases, Clippy should flag the final line and suggest using mul_add.
Instead, this happened:
Clippy remains silent in the missed_opportunity case. It seems the linter loses the ability to track the potential for FMA optimisations as soon as a variable's history includes a floating-point literal that relies on type inference, even when the type is unambiguous.
Version
rustc 1.96.0-nightly (e370b60cf 2026-03-07)
binary: rustc
commit-hash: e370b60cf2b0d3e4b55923ec1558c5b5f8970cfb
commit-date: 2026-03-07
host: x86_64-pc-windows-msvc
release: 1.96.0-nightly
LLVM version: 22.1.0
Summary
The suboptimal_flops lint fails to suggest mul_add when an intermediate variable is used, but only if that variable was initialised using a numeric literal without an explicit type suffix or annotation. If the literal is replaced by a named constant, an explicit type suffix (0.1_f32), or a type annotation on the variable, the lint correctly triggers.
Lint Name
suboptimal_flops
Reproducer
I tried this code:
I expected to see this happen:
In all four cases, Clippy should flag the final line and suggest using mul_add.
Instead, this happened:
Clippy remains silent in the missed_opportunity case. It seems the linter loses the ability to track the potential for FMA optimisations as soon as a variable's history includes a floating-point literal that relies on type inference, even when the type is unambiguous.
Version