BUG: Incorrect mistyped literal suffix on long floats.

[Michael-J-Ward]

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: #3091

$ cargo clippy -V
clippy 0.0.212 (3aea860 2019-09-03)

[hellow554]

Reduced:

const A: f64 = 0.0_32;

this is because of

rust-clippy/clippy_lints/src/literal_representation.rs

Lines 581 to 583 in 1d0f625

	fn is_mistyped_suffix(suffix: &str) -> bool {
	["_8", "_16", "_32", "_64"].contains(&suffix)
	}

[ghost]

I think we shouldn't check for possibly mistyped suffixes in the digits in the fractional part of a literal.

[ghost]

I have some ideas on simplifying the mistyped literal code. If it works out, I'll fix this next.

@rustbot claim

[Michael-J-Ward]

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?

[flip1995]

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.