rust-lang/rust · critical

References to inherent associated consts should have been bl

Error message

References to inherent associated consts should have been blocked

What it means

In `normalize_inherent_associated_term` (inherent.rs), the `AliasTermKind::InherentConst` branch where `is_type_const` is false is explicitly FIXME'd as dead code: references to inherent associated consts (IACs) are supposed to be blocked earlier in HIR lowering. The `panic!` at line 74 fires only if that earlier blocking failed and an IAC reference leaked into the solver.

Source

Thrown at compiler/rustc_next_trait_solver/src/solve/project_goals/inherent.rs:74

        let normalized: I::Term = match inherent.kind {
            ty::AliasTermKind::InherentTy { def_id } => {
                let inherent = cx.type_of(def_id.into()).instantiate(cx, inherent_args);
                let inherent = self.normalize(GoalSource::Misc, goal.param_env, inherent)?;
                inherent.into()
            }
            ty::AliasTermKind::InherentConst { def_id } if cx.is_type_const(def_id.into()) => {
                let inherent = cx.const_of_item(def_id.into()).instantiate(cx, inherent_args);
                let inherent = self.normalize(GoalSource::Misc, goal.param_env, inherent)?;
                inherent.into()
            }
            ty::AliasTermKind::InherentConst { .. } => {
                // FIXME(gca): This is dead code at the moment. It should eventually call
                // self.evaluate_const like projected consts do in consider_impl_candidate in
                // normalizes_to/mod.rs. However, how generic args are represented for IACs is up in
                // the air right now.
                // Will self.evaluate_const eventually take the inherent_args or the impl_args form
                // of args? It might be either.
                panic!("References to inherent associated consts should have been blocked");
            }
            kind => panic!("expected inherent alias, found {kind:?}"),
        };

        self.push_const_arg_has_type_goal(
            goal.param_env,
            goal.predicate.projection_term,
            normalized,
        )?;
        self.eq(goal.param_env, goal.predicate.term, normalized)?;
        self.evaluate_added_goals_and_make_canonical_response(Certainty::Yes)
    }
}

View on GitHub (pinned to 22057b88b0)

Solutions

1. Report at https://github.com/rust-lang/rust/issues — IAC support is incomplete and this is a known gap (note the FIXME in the source).
2. Avoid inherent associated *consts*; use an inherent associated type or a trait associated const instead.
3. Disable `-Znext-solver` and `inherent_associated_types`.
4. `rustup update nightly`.

Example fix

// before — inherent associated const (unsupported)
impl Type { const N: u32 = 3; }
fn f() -> u32 { Type::N } // leaks into solver
// after — use a trait associated const
trait HasN { const N: u32; }
impl HasN for Type { const N: u32 = 3; }
fn f() -> u32 { <Type as HasN>::N }

// Inherent associated consts (IAC) on impl blocks are an unstable feature.
// References to them are expected to be blocked before reaching the solver.
// Validate that you are not referencing an IAC directly.
struct S;
impl S {
    // IAC (requires #![feature(inherent_associated_types)] historically)
    const C: i32 = 42;
}
// GOOD: S::C    (qualified path, value namespace)
// BAD:  <S>::C  used in a type/projection context where it is blocked
fn use_const() -> i32 { S::C }

// Guard against using inherent associated consts in type positions.
// Only use them in value position:
macro_rules! use_iac_value {
    ($t:ty, $c:ident) => { <$t>::$c };
}
// Do not project or normalise IAC names as types; restrict to const-value access.

When it happens

Trigger: HIR lowering fails to reject/redirect a reference to an inherent associated const, so an `InherentConst` projection term reaches `normalize_inherent_associated_term` under `#![feature(inherent_associated_types)]` with `-Znext-solver`.

Common situations: Nightly users experimenting with inherent associated types/consts (IAT/IAC) where the feature is incomplete; typically when referencing an inherent associated const on an impl block, which the language does not yet fully support.

Related errors

• expected inherent alias, found {kind:?}
• we never retry stalled queries if the parent was erased
• this never happens at the root, we're never in erased mode h
• unexpected orig_value: {ty:?}
• unexpected orig_value: {ct:?}

AI-assisted analysis of rust-lang/rust@22057b88b0 (2026-08-03). Data as JSON: /data/errors/0e786a767abfcff1.json. Report an issue: GitHub.