Reduce clippy's complaints about valid decimals

[workingjubilee]

Followup to my hunch in #7666 (comment). I found it was indeed triggering too early in general by naively using the f{32,64}::DIGITS value.

changelog: [excessive_precision] should complain less about valid decimal strings that can be precisely parsed as floats, which clippy was erroneously recommending that you cut 1~3 digits short.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @llogiq (or someone else) soon.

Please see the contribution instructions for more information.

[workingjubilee]

Sigh. Of course the wrong answer is encoded in the test suite several times over.

[bors]

☔ The latest upstream changes (presumably #7722) made this pull request unmergeable. Please resolve the merge conflicts.

[dtolnay]

I don't think this change is faithful to the purpose of this lint. Why would we not suggest replacing 0.123_456_789 with 0.123_456_79, which eliminates the extraneous precision and still represents the identical floating point quantity.

[workingjubilee]

Hmm, I have been wondering about that a little to myself, on reading the code at first I was kind of stunned and confused by the naming of the vars and fn so I didn't examine it closely enough to find all the hidden catches. So let me explain my reasoning more thoroughly. Part of it is somewhat esoteric and may be a better case for recommending this be altered in category, from a style lint to a restriction lint.

It is actually considered "good style" in many situations to use 9 or 17 significant digits. It is necessary for encoding the longer sequences, and faithful replication of the binary value with those 9 or 17 digits is what IEEE754 guarantees. This also matters for, well, the reason that I was alarmed at just using the constant directly: it is common for the character strings of numbers to be blithely copied from language to language. Indeed, most of Rust's float-related constants seem to be lifted from C's <float.h>.

While most language's atoi or equivalent is fairly faithful, some languages have less correct float parsers than Rust's, especially at the edges. So it is possible to introduce floating point error due to variations in parsing, rounding, and formatting between compilers and runtimes. As a general guard against this problem, "over" specifying by a few chars is common, or at least using all 9 or 17 digits. For instance, consider the string values used in Boost, Rust, and OpenCL for pi:

let boost_pi = 3.141592653589793238462643383279502884e+0; // triggers excessive_precision
let rust_pi = 3.14159265358979323846264338327950288f64; // triggers excessive_precision also!
let opencl_pi = 3.141592653589793115998; // triggers excessive_precision AND approx_constant!

// They of course are the same binary value.
assert_eq!(rust_pi, boost_pi);
assert_eq!(rust_pi, opencl_pi);
assert_eq!(rust_pi, std::f64::consts::PI);

Thus, I suppose my disagreement is with the lint per se, or at least what it currently encourages and allows to be machine-applied, since it would likely be preferable to upgrade the type to f64 for many f32 triggers of this lint.

[dtolnay]

Cases like this are fixed a different way by #7722.

[workingjubilee]

Thank you. That change does make me considerably happier with the lint.

[llogiq]

@workingjubilee Sorry for procrastinating on this for so long. What's the status on this PR? Do you intend to go forward with it?

[llogiq]

@workingjubilee ping?

[workingjubilee]

Augh, I don't know. I still have my dissatisfaction with this lint but my irritation has become more vague and I am not sure how I truly want to proceed anymore. It truly irks me that fairly standard code that appears in many codebases, and for good reasons, is linted on. But there are also useful reasons for the lint. Perhaps I want to change it to a restriction lint instead, but I can't seem to muster the internal quorum to agree with myself on that way forward either.

Closing for now, unless you have some particular feedback / opinion.