Change:
LitFloatType::Unsuffixed => None, }; let (is_whole, is_inf, mut float_str) = match fty { <del> FloatTy::F16 => unimplemented!("f16_f128"), </del> <ins> FloatTy::F16 => { // FIXME(f16_f128): do a check like the others when parsing is available return; }, </ins> FloatTy::F32 => { let value = sym_str.parse::<f32>().unwrap();

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: probably from <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
that's expected, the float types are still being 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 for now, so it's expected that clippy would die on such a file.
mvce:
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 (). label -I-prioritize +P-low
Yeah, I will be updating Clippy after I have some slightly improved libs support 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)
this still crashes with latest master and rustc and clippy :/ thread 'rustc' panicked at not implemented: f16_f128 stack backtrace:
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 :sweatsmile: (rustc with -Zcodegen-backend=..) <!-- [31mICE[0m: Rustc '-Zcodegen-backend=cranelift -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'not implemented: '', 'thread 'rustc' panicked at 'not implemented: '' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: --
also fun fact: I found this code from 2014 which also panics again :sweat_smile:
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
is there anything in tree testing this? should fix it but I don't see anything to update if it exists
The above checks fine since but I forgot the tag, could somebody close this?
Ah, that last ICE point should be covered by Is there something edition-specific?
minimized with auto-generated report: <!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'not implemented: '', 'thread 'rustc' panicked at 'not implemented: '' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [thirbody] building THIR for [checkunsafety] unsafety-checking --
does not seem to be edition dependant.

no more in the latest nightly, a previously-panicking test was included in Could we close this broad-ish issue and just open new ones if new ICEs pop up? (There are some s floating around in const casting and math still, but hopefully gone in the next few weeks)
Cranelift still has problems, but I dunno if you want to tackle this :sweatsmile:
Yeah, lower priority :) is tracking that one. cggcc has the issue too but that one is fixed in the rustccodegen_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.