"missing optimized MIR" due to privacy violation, via associated type equality constraint in associated type bound

[theemathas]

This bug was found while investigating #146470, based on the snippet in #146470 (comment). cc @petrochenkov

I tried this code:

src/dep/lib.rs

pub trait ToPriv {
    type AssocPriv;
}

pub trait PubTr {
    #[expect(private_bounds)]
    type Assoc: ToPriv<AssocPriv = Priv>;
}

struct Dummy;
struct DummyToPriv;
impl PubTr for Dummy {
    type Assoc = DummyToPriv;
}
impl ToPriv for DummyToPriv {
    type AssocPriv = Priv;
}

pub fn get_dummy() -> impl PubTr {
    Dummy
}

struct Priv;

pub trait GetUnreachable {
    type Assoc;
}

mod m {
    pub struct Unreachable;

    impl Unreachable {
        #[expect(dead_code)]
        pub fn generic<T>() {}
    }

    impl crate::GetUnreachable for crate::Priv {
        type Assoc = Unreachable;
    }
}

src/main.rs

use dep::{GetUnreachable, PubTr, ToPriv, get_dummy};

fn main() {
    wut(get_dummy());
}

fn wut<T: PubTr>(_: T) {
    <T as Access>::AccessAssoc::generic::<i32>();
}

trait Access: PubTr {
    type AccessAssoc;
}

impl<T: PubTr> Access for T {
    type AccessAssoc = <<T::Assoc as ToPriv>::AssocPriv as GetUnreachable>::Assoc;
}

Compiling the above code resulted in the following error:

error: missing optimized MIR for `dep::m::Unreachable::generic::<i32>` in the crate `dep`
   |
note: missing optimized MIR for this item (was the crate `dep` compiled with `--emit=metadata`?)
  --> dep\src\lib.rs:34:9
   |
34 |         pub fn generic<T>() {}
   |         ^^^^^^^^^^^^^^^^^^^

error: could not compile `foo` (bin "foo") due to 1 previous error

I assume that this error isn't supposed to happen for normal cargo usage.

Meta

rustc --version --verbose:

rustc 1.94.0-nightly (31cd367b9 2026-01-08)
binary: rustc
commit-hash: 31cd367b9ca1ce359268e7adf4ea540408c0ad85
commit-date: 2026-01-08
host: x86_64-pc-windows-msvc
release: 1.94.0-nightly
LLVM version: 21.1.8

[petrochenkov]

Due to Dummy being leaked only in anonymized form (as impl PubTr), I suspect this at least partially to be a bug in EmbargoVisitor (the thing that calculates EffectiveVisibilities).
I'll check.

@theemathas
Could you add some comments to the test case?
What are the components involved into the reproduction, whether they are all necessary, and what every step achieves.
I'm looking at this for relatively long time already, but still don't understand how this works.

[theemathas]

@petrochenkov I don't have a good understanding of the bug either. It was discovered via trial and error with feedback from the compiler. But here's my attempt at explaining how I got to this code (with dead ends omitted, and reordered to hopefully ease understanding).

Based on your snippet, it seems to me that bad things would happen in the compiler if I could directly refer to a private type from outside the crate. So, I tried some stuff to see how I could mention a private type in a public trait. I found that the following code compiles:

pub trait ToPriv {
    type AssocPriv;
}

pub trait PubTr {
    #[expect(private_bounds)]
    type Assoc: ToPriv<AssocPriv = Priv>;
}

struct Priv;

I then needed to give public access to a concrete type that implements PubTr. Having a public type implement PubTr does not work:

Code and error with a public Dummy type

pub trait ToPriv {
    type AssocPriv;
}

pub trait PubTr {
    #[expect(private_bounds)]
    type Assoc: ToPriv<AssocPriv = Priv>;
}

struct Priv;

pub struct Dummy;
pub struct DummyToPriv;
impl PubTr for Dummy {
    type Assoc = DummyToPriv;
}
impl ToPriv for DummyToPriv {
    type AssocPriv = Priv;
}

error[E0446]: private type `Priv` in public interface
  --> src/lib.rs:18:5
   |
10 | struct Priv;
   | ----------- `Priv` declared as private
...
18 |     type AssocPriv = Priv;
   |     ^^^^^^^^^^^^^^ can't leak private type

For more information about this error, try `rustc --explain E0446`.

I reasoned that I needed to only expose as "public knowledge" that this concrete type Dummy implements PubTr, but not expose the ToPriv impl. This led to the get_dummy function, which returns the type impl PubTr, without mentioning what its associated type is.

Combined with the Unreachable and GetUnreachable setup from your snippet, we now arrive at the contents of dep/src/lib.rs in the above issue.

However, attempting to access Unreachable via this chain of traits directly does not compile.

Code and error when attempting to directly access Unreachable

use dep::{GetUnreachable, PubTr, ToPriv, get_dummy};

fn main() {
    wut(get_dummy());
}

fn wut<T: PubTr>(_: T) {
    <<T::Assoc as ToPriv>::AssocPriv as GetUnreachable>::Assoc::generic::<i32>();
}

error: type `dep::Priv` is private
 --> src\main.rs:8:6
  |
8 |     <<T::Assoc as ToPriv>::AssocPriv as GetUnreachable>::Assoc::gen...
  |      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ private type

I reasoned that the compiler tried to normalize stuff and ran into the dep::Priv type. I guessed that making things "more generic" would likely prevent this normalization. After some trial and error, I arrived at the contents of src/main.rs in the above issue, although I don't understand why this prevented normalization.

[petrochenkov]

I suspect this at least partially to be a bug in EmbargoVisitor

Added the test case from this issue to #151168.
EmbargoVisitor fixes didn't affect it.

[petrochenkov]

In fn get_dummy() -> impl PubTr the return type has some concrete generic argument impl PubTr<Assoc = ???>.
I wonder what rustc things it is.
When I attempt to fill it in explicitly, it always results in a privacy error one way or another.
I suspect that in impl Trait<Assoc = ???> we need to check ??? for privacy even if it's not written explicitly.