Skip to content

Type inference failure for f32 #123824

Closed

Description

@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.

Activity

  1. added
    needs-triageThis issue may need triage. Remove when done. See docs forge.rust-lang.org/release/issue-triaging
    on Apr 11, 2024
  2. changed the title [-]Type inference failure for f32[/-] [+]Type inference failure for `f32`[/+] on Apr 11, 2024
  3. added
    T-langRelevant to the language team
    T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
    on Apr 11, 2024
  4. jieyouxu commented on Apr 11, 2024

    @jieyouxu
    Member

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

  5. added
    S-has-mcveStatus: A Minimal Complete and Verifiable Example has been found for this issue
    T-libsRelevant to the library team, which will review and decide on the PR/issue.
    and removed
    T-langRelevant to the language team
    on Apr 11, 2024
  6. tgross35 commented on Apr 11, 2024

    @tgross35
    Member
  7. Nemo157 commented on Apr 11, 2024

    @Nemo157
    Contributor

    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.

  8. workingjubilee commented on Apr 11, 2024

    @workingjubilee
    Member

    Correct.

  9. tgross35 commented on Apr 11, 2024

    @tgross35
    Member

    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);
    }
  10. tgross35 commented on Apr 11, 2024

    @tgross35
    Member

    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

  11. 5 remaining items

  12. tgross35 commented on Apr 11, 2024

    @tgross35
    Member

    Race condition 😆

    image
  13. jieyouxu commented on Apr 11, 2024

    @jieyouxu
    Member

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

  14. fmease commented on Apr 11, 2024

    @fmease
    Member

    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.

  15. tgross35 commented on Apr 11, 2024

    @tgross35
    Member

    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!

  16. tgross35 commented on Apr 12, 2024

    @tgross35
    Member

    @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.

  17. P1n3appl3 commented on Apr 12, 2024

    @P1n3appl3
    ContributorAuthor

    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).

  18. added a commit that references this issue on Apr 12, 2024
  19. added a commit that references this issue on Apr 12, 2024
  20. BD103 commented on Apr 12, 2024

    @BD103
    Contributor

    @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).

  21. tgross35 commented on Apr 12, 2024

    @tgross35
    Member

    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?).

  22. added a commit that references this issue on May 5, 2024
  23. added a commit that references this issue on May 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-inferenceArea: Type inferenceC-bugCategory: This is a bug.F-f16_and_f128`#![feature(f16)]`, `#![feature(f128)]`S-has-mcveStatus: A Minimal Complete and Verifiable Example has been found for this issueT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.T-libsRelevant to the library team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions