Repository navigation
Closed
Labels
A-inferenceArea: Type inferenceArea: Type inferenceC-bugCategory: This is a bug.Category: This is a bug.F-f16_and_f128`#![feature(f16)]`, `#![feature(f128)]``#![feature(f16)]`, `#![feature(f128)]`S-has-mcveStatus: A Minimal Complete and Verifiable Example has been found for this issueStatus: 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.Relevant 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.Relevant to the library team, which will review and decide on the PR/issue.
Description
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 errorI 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.
Metadata
Metadata
Assignees
Labels
A-inferenceArea: Type inferenceArea: Type inferenceC-bugCategory: This is a bug.Category: This is a bug.F-f16_and_f128`#![feature(f16)]`, `#![feature(f128)]``#![feature(f16)]`, `#![feature(f128)]`S-has-mcveStatus: A Minimal Complete and Verifiable Example has been found for this issueStatus: 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.Relevant 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.Relevant to the library team, which will review and decide on the PR/issue.
Activity
[-]Type inference failure for f32[/-][+]Type inference failure for `f32`[/+]jieyouxu commentedon Apr 11, 2024
cc @tgross35: is it possible that adding the the
Fromimpls forf16/f128may have caused type inference regression here?tgross35 commentedon Apr 11, 2024
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 commentedon Apr 11, 2024
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
f64for floating point.workingjubilee commentedon Apr 11, 2024
Correct.
tgross35 commentedon Apr 11, 2024
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 f64tgross35 commentedon Apr 11, 2024
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
5 remaining items
tgross35 commentedon Apr 11, 2024
Race condition 😆
jieyouxu commentedon Apr 11, 2024
I did not remove the feature label lol (it wasn't even in the list), welldone GitHub 😆
fmease commentedon Apr 11, 2024
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.Remove `From` impls for unstable types that break inference
Remove `From` impls for unstable types that break inference
tgross35 commentedon Apr 11, 2024
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 commentedon Apr 12, 2024
@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 commentedon Apr 12, 2024
This was the one that we caught it on. It's a pretty simple case (that
Coordtype is just anf32type 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).Rollup merge of rust-lang#123830 - tgross35:f16-f128-from-inference-f…
Unrolled build for rust-lang#123830
BD103 commentedon Apr 12, 2024
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 commentedon Apr 12, 2024
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?).
Auto merge of rust-lang#124728 - beetrees:from-f16-for-f64, r=<try>
Auto merge of rust-lang#124728 - beetrees:from-f16-for-f64, r=BurntSushi