excessive_precision should not lint when it's so excessive as to be clearly intentional

[scottmcm]

Summary

Like how rust defines constants with clearly more precision than needed,

https://github.com/rust-lang/rust/blob/5dfe648b45659db8dd0a673a806bba3df84aa3af/library/core/src/num/f32.rs#L348-L358

For mathematical constants (that aren't already in fNN::consts) it's nice to just paste in the full value with way more precision that you could ever need, like

let γ = 0.5772156649015328606065120900824024310421;

That's 40 decimal sigfigs, aka about 132 binary sigfigs, which is well more than is needed for any built-in float type (even f128 is only ≈33 decimal sigfigs).

And changing that to

let γ = 0.577_215_7;

as clippy suggests obfuscates more than it helps, plus it makes it harder if you change from f32 to f64 in the future.

For constants that have just slightly too much precision, especially things that look like integers, this lint makes sense.

But when the coder is clearly not thinking that it'll be exactly representable -- I'll toss that 40 sigfig threshold as a first stab at how clippy could know that -- then telling them that there's excess precision is not valuable, and clippy should let it go.

(Other things you could consider here are things like suppressing it for consts defined with a type and a particularly-precise literal, or something.)

Lint Name

excessive_precision

Reproducer

No response

Version

Additional Labels

No response

[teofr]

Hey, I'd like to help with this issue, I'm not sure if the decision is made about setting a number of digits from which suppress the lint (suggested 40 in the issue) or if it's still up for discussion. I see a couple of options/questions around it:

• Do we want to suppress the lint to every literal? Only literals assigned directly to a variable? to a const?
• On the original comment raising this issue, they suggest truncating the literal but adding the full constant as a comment, maybe this fix could be suggested instead?

In my opinion this suppression should only happen with const items. A bit less certain about whether to just suppress the lint, or change its behavior (suggesting a comment as well as the truncation). But would like to hear from the mantainers.

@rustbot claim

[scottmcm]

In my opinion this suppression should only happen with const items.

That would 100% have resolved the original case where I hit this, so that sounds reasonable to me. I like that it would let the lint offer "or you can make a const" as another way of having it not fire, rather than the only option being allowing it.

---

That would probably also be nice for macros, since today this lints:

macro_rules! make_pi {
    ($i:ident : $t:ty) => { const $i : $t = 3.14159265358979323846264338327950288419716939937510582097494459230781640628; }
}

fn main() {
    make_pi!(P32: f32);
    make_pi!(P64: f64);
    dbg!(P32, P64);
}

And there's no way to write a constant in there that's both correct and passes the lint in both constants.

The only versions that don't lint (and don't just allow) are incorrect things like

macro_rules! make_pi {
    ($i:ident : $t:ty) => { const $i : $t = 3.141592; }
}