-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ICE: not implemented: f16_f128
#122587
Comments
that's expected, the float types are still being added and will panic, please don't fuzz them yet. |
the file is from the rustc repo, have you not read the ticket? |
Yes, the file tests that float name resolution works. A lot of areas, including clippy, are stubbed out with |
mvce: const b: f16 = 0.0f16;
pub fn main() {
let b = 0.0f16;
} |
With the current way feature gating works, it's inevitable that it will lead to these kinds of problems. it might make sense to make feature gating fatal. either way I don't think this has a particularly high priority |
WG-prioritization assigning priority (Zulip discussion). @rustbot label -I-prioritize +P-low |
Yeah, I will be updating Clippy after I have some slightly improved libs support @rustbot claim |
Feel free to ping / assign me on any f16/f128 issues btw |
As an org member, I think you should be able to configure notifications for this repo so that you get notified whenever someone applies the F label. |
Thanks, I had no clue that was a thing. Awesome. (looks like you don't even need to be an org member to do this, just tried with something else) |
It turns out there is a bit of a circular dependency - I cannot add anything to `core` because Clippy fails, and I can't actually add correct Clippy implementations without new implementations from `core`. Change some of the Clippy stubs from `unimplemented!` to success values and leave a FIXME in their place to mitigate this. Fixes <rust-lang#122587>
It turns out there is a bit of a circular dependency - I cannot add anything to `core` because Clippy fails, and I can't actually add correct Clippy implementations without new implementations from `core`. Change some of the Clippy stubs from `unimplemented!` to success values and leave a FIXME in their place to mitigate this. Fixes <rust-lang#122587>
It turns out there is a bit of a circular dependency - I cannot add anything to `core` because Clippy fails, and I can't actually add correct Clippy implementations without new implementations from `core`. Change some of the Clippy stubs from `unimplemented!` to success values and leave a FIXME in their place to mitigate this. Fixes <rust-lang#122587>
…bs, r=blyxyas Change `f16` and `f128` clippy stubs to be nonpanicking It turns out there is a bit of a circular dependency - I cannot add anything to `core` because Clippy fails, and I can't actually add correct Clippy implementations without new implementations from `core`. Change some of the Clippy stubs from `unimplemented!` to success values and leave a FIXME in their place to mitigate this. Fixes <rust-lang#122587>
@tgross35 this still crashes with latest master and rustc and clippy :/ thread 'rustc' panicked at compiler/rustc_mir_build/src/thir/pattern/const_to_pat.rs:445:41: |
Hmm which line does it say it's panicking at? I am running with
That seems to work fine, not sure if there is a less clunky way to build and run clippy in-tree |
ooh lol its actually cranelift that panics 😅 (rustc with -Zcodegen-backend=..) auto-reduced (treereduce-rust): #![feature(f128)]
mod check_f128 {
pub fn foo() {
bar(1.23);
}
fn bar(a: f128) {}
}
fn main() {
check_f128::foo();
}
original: //@ run-pass
#![allow(unused)]
#![feature(f128)]
#![feature(f16)]
// Same as the feature gate tests but ensure we can use the types
mod check_f128 {
const A: f128 = 10.0;
pub fn foo() {
let a: f128 = 100.0;
let b = 0.0f128;
bar(1.23);
}
fn bar(a: f128) {}
struct Bar {
a: f128,
}
}
mod check_f16 {
const A: f16 = 10.0;
pub fn foo() {
let a: f16 = 100.0;
let b = 0.0f16;
bar(1.23);
}
fn bar(a: f16) {}
struct Bar {
a: f16,
}
}
fn main() {
check_f128::foo();
check_f16::foo();
} Version information
Command: Program output
|
…xyas Change `f16` and `f128` clippy stubs to be nonpanicking It turns out there is a bit of a circular dependency - I cannot add anything to `core` because Clippy fails, and I can't actually add correct Clippy implementations without new implementations from `core`. Change some of the Clippy stubs from `unimplemented!` to success values and leave a FIXME in their place to mitigate this. Fixes <rust-lang/rust#122587>
It turns out there is a bit of a circular dependency - I cannot add anything to `core` because Clippy fails, and I can't actually add correct Clippy implementations without new implementations from `core`. Change some of the Clippy stubs from `unimplemented!` to success values and leave a FIXME in their place to mitigate this. Fixes <rust-lang/rust#122587>
also fun fact: I found this code from 2014 which also panics again 😅 #![feature(quad_precision_float)]
static x: f128 = 1.0 + 2.0;
fn foo(a: f128) -> f128 { a }
pub fn main() {
let y = x;
foo(y);
} |
I don't even think the old gate is needed for that (though funny that it exists). Unfortunately anything that can get const evaled will ICE until I can update that portion of the code, which can't happen until we have arithmetic working on all platforms, which won't work until I have compiler_builtins updated, which is a huge pain that I am currently working on... Dependencies 😆 |
@matthiaskrgr is there anything in tree testing this? #126636 should fix it but I don't see anything to update if it exists |
The above checks fine since #126636 but I forgot the |
|
Ah, that last ICE point should be covered by #123088. Is there something edition-specific? |
minimized with auto-generated report: auto-reduced (treereduce-rust): const b: f16 = 10.0;
pub fn main() {
let b = 0.0f16;
foo(1.23);
}
fn foo(a: f16) {}
original: //@ revisions: e2015 e2018
//
//@[e2018] edition:2018
#![allow(unused)]
const b: f16 = 10.0; //~ ERROR the type `f16` is unstable
pub fn main() {
let a: f16 = 100.0; //~ ERROR the type `f16` is unstable
let b = 0.0f16; //~ ERROR the type `f16` is unstable
foo(1.23);
}
fn foo(a: f16) {} //~ ERROR the type `f16` is unstable
struct Bar {
a: f16, //~ ERROR the type `f16` is unstable
} Version information
Command: Program output
|
does not seem to be edition dependant. |
@matthiaskrgr no more 🧊 in the latest nightly, a previously-panicking test was included in https://github.com/rust-lang/rust/blob/fda509e817abeeecb5b76bc1de844f355675c81e/tests/ui/consts/const_in_pattern/f16-f128-const-reassign.rs. Could we close this broad-ish issue and just open new ones if new ICEs pop up? (There are some |
Cranelift still has problems, but I dunno if you want to tackle this 😅 |
Yeah, lower priority :) rust-lang/rustc_codegen_cranelift#1461 is tracking that one. cg_gcc has the issue too but that one is fixed in the rustc_codegen_gcc repo, just waiting on a sync. |
Going to close this since the obvious codepaths have been taken care of, anything less obvious is probably better off in its own issue. |
Code
Meta
rustc --version --verbose
:probably from #121926
Error output
clippy-driver ./tests/ui/resolve/primitive-usage.rs
Backtrace
The text was updated successfully, but these errors were encountered: