I have a long literal float, which clippy warns that it lacks literal separators:
warning: long literal lacking separators
--> src/lib.rs:58:35
|
58 | const EARTH_YEAR_RATIO: f64 = 164.79132032;
| ^^^^^^^^^^^^ help: consider: `164.791_320_32`
|
= note: `#[warn(clippy::unreadable_literal)]` on by default
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#unreadable_literal
But after fixing it, clippy gives an error saying mistyped literal suffix
error: mistyped literal suffix
--> src/lib.rs:58:35
|
58 | const EARTH_YEAR_RATIO: f64 = 164.791_320_32;
| ^^^^^^^^^^^^^^ help: did you mean to write: `164.791_320_f32`
|
= note: `#[deny(clippy::mistyped_literal_suffixes)]` on by default
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#mistyped_literal_suffixes
Related to: https://github.com/rust-lang/rust-clippy/issues/3091
$ cargo clippy -V
clippy 0.0.212 (3aea860 2019-09-03)
Reduced:
const A: f64 = 0.0_32;
this is because of https://github.com/rust-lang/rust-clippy/blob/1d0f62570b2f58b09b991f7312dd1f1564c613f0/clippy_lints/src/literal_representation.rs#L581-L583
I think we shouldn't check for possibly mistyped suffixes in the digits in the fractional part of a literal.
I have some ideas on simplifying the mistyped literal code. If it works out, I'll fix this next.
@rustbot claim
Just a thought as the user- the thing that surprised me was the cycle: i.e. one fix suggestion triggered another error. Is it feasible / desirable to catch this by running the suggested fix itself back through clippy?
We do this, if applicable. No idea, why we don't do this here.
Probably it's just that we forgot to add a test case for this.
Most helpful comment
I think we shouldn't check for possibly mistyped suffixes in the digits in the fractional part of a literal.