Repository navigation
Regression 1.96.1 → 1.97.0: "missing optimized MIR" for pub fn glob-reexported alongside a restricted glob duplicate #159038
Description
Building a crate that calls dep::f() fails with error: missing optimized MIR for `f` in the crate `dep` when f — an ordinary non-generic pub fn — is exported from dep only through a public glob re-export and a second, private glob also imports it into the same module with restricted visibility. 1.96.1 compiles this fine; 1.97.0 fails. Found while building a private ~16-crate workspace.
Reproduction
// dep/src/lib.rs
mod inner {
pub fn f() -> u32 { 42 }
}
mod facade {
pub(crate) use super::inner::f;
}
#[allow(unused_imports)]
use facade::*;
pub use inner::*;
// app/src/lib.rs (app depends on dep by path)
pub fn call_f() -> u32 { dep::f() }$ cargo +1.96.1 build --release
warning: unused import: `super::inner::f`
Finished `release` profile [optimized] target(s) in 0.25s
$ cargo +1.97.0 build --release
warning: unused import: `super::inner::f`
warning: function `f` is never used
error: missing optimized MIR for `f` in the crate `dep`
|
note: missing optimized MIR for this item (was the crate `dep` compiled with `--emit=metadata`?)
error: could not compile `app` (lib) due to 1 previous errorAlso fails in default cargo build (see details), on 1.98.0-beta.1, and on 1.99.0-nightly (2026-07-08). Nightly only: RUSTFLAGS=-Zalways-encode-mir masks it.
Mechanism
Two queries disagree about f. Name resolution still exports it at pub — dep::f resolves fine downstream and f stays cross_crate_inlinable — but the effective-visibility computation walks only the first-arrived glob declaration's reexport chain (here the restricted facade route), capping f at pub(crate). Everything driven by effective visibilities then treats f as not exported: the new spurious function `f` is never used warning above is the tell, f drops out of reachable_set, and should_encode_mir skips encoding its optimized MIR while downstream crates still try to inline it — hence the collector error.
Bisection
With cargo bisect-rustc v0.6.11 (plain cargo build of the repro, --regress error):
searched nightlies: from nightly-2026-04-05 to nightly-2026-05-10
regressed nightly: nightly-2026-05-01
regressed commit: https://github.com/rust-lang/rust/commit/a021a7796f66600f46013d6c8d1dfc9e8d7f4a92 (rollup #155979)
Likely PR: #154149 (resolve: Extend ambiguous_import_visibilities deprecation lint to glob-vs-glob ambiguities) — the only shape-matching PR in the rollup; corroboration in the details below.
We have a validated fix: fix PR: #159039.
Version
rustc 1.97.0 (2d8144b78 2026-07-07)
binary: rustc
commit-hash: 2d8144b7880597b6e6d3dfd63a9a9efae3f533d3
commit-date: 2026-07-07
host: aarch64-apple-darwin
release: 1.97.0
LLVM version: 22.1.6
Minimization matrix, in-cycle history, corroboration
Load-bearing (removing any one makes the error disappear): (1) the fn is exported only via a glob (pub use inner::*; — an explicit pub use inner::f; builds fine); (2) a second private module re-exports the same item with restricted visibility (pub(crate) use super::inner::f;; pub(super) also reproduces, a plain private use does not); (3) the crate root glob-imports that facade privately (use facade::*;); (4) a downstream crate references the item (the error fires during the downstream crate's monomorphization; cargo check passes).
Not load-bearing (all verified to still reproduce): profile keys (opt-level 0/1/2/3/"s", lto, codegen-units=1, panic="abort", strip), debug vs release (the minimal repro fails even in default cargo build; the original workspace needed --release only because its larger function is cross-crate-inlinable only when optimizing), editions 2015/2021/2024, #[inline]/#[inline(never)], incremental on/off, clean target dir.
The repro's behavior flips twice more inside the 1.97 cycle, both in direct follow-ups to #154149, pinning the mechanism: nightly-2026-05-06 (e95e73209, rollup #156190, contains #156014) turns the silent failure into a hard E0364 on the private glob; nightly-2026-05-13 (8b03437a8, rollup #156506, contains #156284) suppresses that diagnostic for ambiguous glob sets but leaves the underlying effective-visibility data wrong — the state that shipped in 1.97.0.
Corroboration: #157420 (1.97 unused_imports false positive on a glob re-export) was independently bisected to the same nightly-2026-05-01 and attributed to #154149; its fix #157713 does not fix this issue (nightly-2026-07-08 still fails). #156264 (E0365 false positive on pub(crate) re-exports, fixed by #156284) is another earlier-caught symptom of the same change.
Workarounds: make the public re-export explicit (pub use inner::f;), or drop the restricted facade re-export; pin 1.96.1; nightly only, -Zalways-encode-mir.
@rustbot label +regression-from-stable-to-stable +A-resolve +A-visibility +T-compiler +C-bug +S-has-bisection
Activity
Rollup merge of rust-lang#159039 - calvinrp:fix/effective-vis-glob-am…
Rollup merge of rust-lang#159039 - calvinrp:fix/effective-vis-glob-am…
Rollup merge of rust-lang#159039 - calvinrp:fix/effective-vis-glob-am…
Rollup merge of rust-lang#159039 - calvinrp:fix/effective-vis-glob-am…
3 remaining items
Rollup merge of rust-lang#159039 - calvinrp:fix/effective-vis-glob-am…
Rollup merge of rust-lang#159039 - calvinrp:fix/effective-vis-glob-am…
Auto merge of #159039 - calvinrp:fix/effective-vis-glob-ambiguity, r=…
Rollup merge of rust-lang#159039 - calvinrp:fix/effective-vis-glob-am…
Auto merge of #159039 - calvinrp:fix/effective-vis-glob-ambiguity, r=…
Rollup merge of rust-lang#159039 - calvinrp:fix/effective-vis-glob-am…
Rollup merge of rust-lang#159039 - calvinrp:fix/effective-vis-glob-am…
Auto merge of #159039 - calvinrp:fix/effective-vis-glob-ambiguity, r=…
Unrolled build for #159039
Mark-Simulacrum commentedon Jul 14, 2026
Reopening to track potential backports.
Rollup merge of rust-lang#161024 - calvinrp:fix/pub-visibility, r=pet…
Unrolled build for #161024
Rollup merge of #161024 - calvinrp:fix/pub-visibility, r=petrochenkov