-
Notifications
You must be signed in to change notification settings - Fork 13.2k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # 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: