regression: f16 + f128 is unstable

[Mark-Simulacrum]

[INFO] [stdout] error[E0658]: the type `f16` is unstable
[INFO] [stdout]  --> src/float.rs:5:9
[INFO] [stdout]   |
[INFO] [stdout] 5 | pub use f16::*;
[INFO] [stdout]   |         ^^^
[INFO] [stdout]   |
[INFO] [stdout]   = note: see issue #116909 <https://github.com/rust-lang/rust/issues/116909> for more information

• https://crater-reports.s3.amazonaws.com/beta-1.78-3/beta-2024-03-30/gh/Cyborus04.more_nums/log.txt
• https://crater-reports.s3.amazonaws.com/beta-1.78-3/beta-2024-03-30/gh/jthomme1.gen_smooth/log.txt

[fmease]

cc @tgross35

[Noratrieb]

MCVE:

mod f16 { pub fn a() {} }

pub use f16::a;

[Noratrieb]

It compiles if I add #![feature(f16)]. Somehow feature gating and name resolution disagree whether it refers to the type or the module.

mod f32 { pub fn a() {} }

pub use f32::a;

also compiles

[Noratrieb]

I think this was fixed recently? It reproduces on the playground nightly, but does not reproduce on the latest nightly and on master.

[Noratrieb]

Ah no, I can reproduce it with cargo build, just not with rustc directly (?????????).

[Noratrieb]

cc @petrochenkov @compiler-errors, it was probably regressed by e782d27

[fmease]

Ah no, I can reproduce it with cargo build, just not with rustc directly (?????????).

rustc defaults to Rust 2015 and cargo init; cargo b to Rust 2021. And the MCVE only fails in Rust >=2018.

[tgross35]

I am looking at this but it may take me a bit to have a solution. What is the timeline like to have a candidate fix vs. reverting?

[Mark-Simulacrum]

We will want a backportable (i.e. relatively small, limited impact) fix in the next 2-3 weeks. We're about a month out from the 1.78 release.

[compiler-errors]

Well given that f16/f128 is nightly-only, I don't see why we would want to fix this over reverting. @tgross35: Let's just revert it on beta, and try to fix it on nightly.

[apiraino]

WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-high

[petrochenkov]

Something wrong is going on here.
In the reproduction the resolution should never touch primitive f16 with finalize enabled.
I'll check.

[petrochenkov]

Fix:

--- a/compiler/rustc_resolve/src/ident.rs
+++ b/compiler/rustc_resolve/src/ident.rs
@@ -605,6 +605,7 @@ struct Flags: u8 {
                                 && !this.tcx.features().f16
                                 && !ident.span.allows_unstable(sym::f16)
                                 && finalize.is_some()
+                                && innermost_result.is_none()
                             {
                                 feature_err(
                                     this.tcx.sess,
@@ -618,6 +619,7 @@ struct Flags: u8 {
                                 && !this.tcx.features().f128
                                 && !ident.span.allows_unstable(sym::f128)
                                 && finalize.is_some()
+                                && innermost_result.is_none()
                             {
                                 feature_err(
                                     this.tcx.sess,

[tgross35]

Ah I shouldn't have included a fixes: tag, this needs to be reopened.

Since the fix is small, I'll put up a beta PR with the cherry pick as long as that seems reasonable in favor of reverting.

[tgross35]

Up at #123445

[fmease]

Ah I shouldn't have included a fixes: tag, this needs to be reopened.

[tgross35]

Ah I shouldn't have included a fixes: tag, this needs to be reopened.

Well, now it can be closed again 😄 #123466 should hopefully fix this.