Prefer new associated numeric consts in float error messages

[bstrie]

This program:

fn main() {
    let _ =  3.40282357e+38_f32;
    let _ =  1.7976931348623159e+308_f64;
}

Produces this output:

error: literal out of range for `f32`
 --> src/main.rs:2:14
  |
2 |     let _ =  3.40282357e+38_f32;
  |              ^^^^^^^^^^^^^^^^^^
  |
  = note: `#[deny(overflowing_literals)]` on by default
  = note: the literal `3.40282357e+38_f32` does not fit into the type `f32` and will be converted to `std::f32::INFINITY`

error: literal out of range for `f64`
 --> src/main.rs:3:14
  |
3 |     let _ =  1.7976931348623159e+308_f64;
  |              ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: the literal `1.7976931348623159e+308_f64` does not fit into the type `f64` and will be converted to `std::f64::INFINITY`

Note the references to std::{f32, 64}::INFINITY; these symbols have been superseded by associated consts at {f32,f64}::INFINITY (#68490).

1. Update the error message to suggest the new symbols

2. Determine if any of the other old symbols are contained in any error messages.

[bstrie]

See also #73194.

[0xPoe]

I am working on this.
@rustbot claim

[bstrie]

@estebank :

I think there are other cases where we still use the old mod consts.

I've gone and grepped through compiler/ for std::i8, std::f32, etc. and found no accidental uses there. I then grepped for each of the individual symbols listed in RFC 2700 (INFINTY, MAX, etc.) and didn't notice anything out of place. I also grepped for std::{} (as seen in this issue) and found only a hint message for things like f32::consts::PI etc which only triggers when an item isn't found at all, which won't trigger for any of the new consts. Probably safe to close this once #78431 merges.

[estebank]

You are right. I was thinking of cases like this one https://github.com/rust-lang/rust/blob/0baf61bfdb95980c69fbfcc0fc95ce82e8d81ac9/src/test/ui/suggestions/suggest-std-when-using-type.stderr but this can likely be closed with the merge of that PR. I was operating with an abundance of caution.

[bstrie]

Yeah, that's the aforementioned case that only shows up in the event of an error, so (AFAICT) that path won't be taken for the new constants since they resolve successfully.