Type inference failure for f32

[P1n3appl3]

After this rollup we started seeing the following compile failure:

fn main() {
    let x = f32::from(3.14);
}

error[E0277]: the trait bound `f32: From<f64>` is not satisfied
  --> /tmp/repro.rs:2:13
   |
16 |     let x = f32::from(3.14);
   |             ^^^ the trait `From<f64>` is not implemented for `f32`
   |
   = help: the following other types implement trait `From<T>`:
             <f32 as From<bool>>
             <f32 as From<f16>>
             <f32 as From<i16>>
             <f32 as From<i8>>
             <f32 as From<u16>>
             <f32 as From<u8>>

error: aborting due to 1 previous error

I repro'd this locally on aa6a697 but we have CI that runs on every commit so we're fairly sure that it started with 4435924. Of the changes in that rollup #122470 is the only one that seemed to touch float stuff, but I'm not sure how adding some extra impls for f16 and f128 would break inference in this case.

[jieyouxu]

cc @tgross35: is it possible that adding the the From impls for f16/f128 may have caused type inference regression here?

[tgross35]

It must be, but I don't know why since https://github.com/rust-lang/rust/pull/122470/files#diff-154dff23a2c2f4fb97915229fd9c27d73293940250088020bfd2074094186ce4R171 wasn't touched. Also reproduced locally

[Nemo157]

When there is only one applicable impl it can guide inference, as soon as there are multiple it can't use those and instead goes to default-numeric-fallback which appears to be f64 for floating point.

[workingjubilee]

Correct.

[tgross35]

Just coming to the same conclusion - the literal is getting guided to f32 on stable since that's the only type that fits the from, but when there are more options it gets the default float literal type of f64

fn main() {
    let a = 3.14;
    dbg!(std::any::type_name_of_val(&a)); // prints f32 on stable
    let x = f32::from(a);
}

[tgross35]

I'll put up a PR to remove these impls for now but what is the correct longer term fix?

cc @rust-lang/libs-api

[tgross35]

@rustbot label -needs-triage +A-inference +F-f16_and_f128

[tgross35]

Race condition 😆

[jieyouxu]

I did not remove the feature label lol (it wasn't even in the list), welldone GitHub 😆

[fmease]

Theoretically, type inference regressions are permitted as part of Rust's 1.0 stability guarantees.

In practice, if the regressions are too bad, the changes usually get reverted and are subsequently blocked indefinitely iirc.

However, we could make use of editions if the worst comes to the worst. See arrays & IntoIterator. I think we have something similar queued up for Rust 2024. On mobile, can't link.

[tgross35]

I put a fix up at #123830 and opened #123831 to further discuss what we want to do here.

Thanks @P1n3appl3 for identifying this so quick!

[tgross35]

@P1n3appl3 if you get the chance, could you link some of the places that caused this failure? It would be good to have some references for how this behavior is being relied on in the wild.

[P1n3appl3]

This was the one that we caught it on. It's a pretty simple case (that Coord type is just an f32 type alias) and seems reasonable to break on an edition boundary (or even just on a release as long as there's a machine applicable suggestion to fix it).

[BD103]

@P1n3appl3 if you get the chance, could you link some of the places that caused this failure? It would be good to have some references for how this behavior is being relied on in the wild.

Hi! I'm from the Bevy project. We caught this bug with this run too, though the error originates from the Taffy crate (0.3.18).

[tgross35]

Awesome, thanks for the report! I started a list of known regressions at #123831, and there is a crater run going to figure out how best to deal with this behavior.

The fix for this was merged so should be available on the next nightly (couple of hours?).