{"id":"0e786a767abfcff1","repo":"rust-lang/rust","slug":"references-to-inherent-associated-consts-should-ha","errorCode":null,"errorMessage":"References to inherent associated consts should have been blocked","messagePattern":"References to inherent associated consts should have been blocked","errorType":"panic","errorClass":null,"httpStatus":null,"severity":"critical","filePath":"compiler/rustc_next_trait_solver/src/solve/project_goals/inherent.rs","lineNumber":74,"sourceCode":"        let normalized: I::Term = match inherent.kind {\n            ty::AliasTermKind::InherentTy { def_id } => {\n                let inherent = cx.type_of(def_id.into()).instantiate(cx, inherent_args);\n                let inherent = self.normalize(GoalSource::Misc, goal.param_env, inherent)?;\n                inherent.into()\n            }\n            ty::AliasTermKind::InherentConst { def_id } if cx.is_type_const(def_id.into()) => {\n                let inherent = cx.const_of_item(def_id.into()).instantiate(cx, inherent_args);\n                let inherent = self.normalize(GoalSource::Misc, goal.param_env, inherent)?;\n                inherent.into()\n            }\n            ty::AliasTermKind::InherentConst { .. } => {\n                // FIXME(gca): This is dead code at the moment. It should eventually call\n                // self.evaluate_const like projected consts do in consider_impl_candidate in\n                // normalizes_to/mod.rs. However, how generic args are represented for IACs is up in\n                // the air right now.\n                // Will self.evaluate_const eventually take the inherent_args or the impl_args form\n                // of args? It might be either.\n                panic!(\"References to inherent associated consts should have been blocked\");\n            }\n            kind => panic!(\"expected inherent alias, found {kind:?}\"),\n        };\n\n        self.push_const_arg_has_type_goal(\n            goal.param_env,\n            goal.predicate.projection_term,\n            normalized,\n        )?;\n        self.eq(goal.param_env, goal.predicate.term, normalized)?;\n        self.evaluate_added_goals_and_make_canonical_response(Certainty::Yes)\n    }\n}\n","sourceCodeStart":56,"sourceCodeEnd":88,"githubUrl":"https://github.com/rust-lang/rust/blob/22057b88b091743bc0fd8d592a9264f0a6951403/compiler/rustc_next_trait_solver/src/solve/project_goals/inherent.rs#L56-L88","documentation":"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.","triggerScenarios":"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`.","commonSituations":"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.","solutions":["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).","Avoid inherent associated *consts*; use an inherent associated type or a trait associated const instead.","Disable `-Znext-solver` and `inherent_associated_types`.","`rustup update nightly`."],"exampleFix":"// before — inherent associated const (unsupported)\nimpl Type { const N: u32 = 3; }\nfn f() -> u32 { Type::N } // leaks into solver\n// after — use a trait associated const\ntrait HasN { const N: u32; }\nimpl HasN for Type { const N: u32 = 3; }\nfn f() -> u32 { <Type as HasN>::N }","handlingStrategy":"type-guard","validationCode":"// Inherent associated consts (IAC) on impl blocks are an unstable feature.\n// References to them are expected to be blocked before reaching the solver.\n// Validate that you are not referencing an IAC directly.\nstruct S;\nimpl S {\n    // IAC (requires #![feature(inherent_associated_types)] historically)\n    const C: i32 = 42;\n}\n// GOOD: S::C    (qualified path, value namespace)\n// BAD:  <S>::C  used in a type/projection context where it is blocked\nfn use_const() -> i32 { S::C }","typeGuard":"// Guard against using inherent associated consts in type positions.\n// Only use them in value position:\nmacro_rules! use_iac_value {\n    ($t:ty, $c:ident) => { <$t>::$c };\n}\n// Do not project or normalise IAC names as types; restrict to const-value access.","tryCatchPattern":null,"preventionTips":["Inherent associated consts are unstable; prefer associated consts on a trait or a top-level const to avoid the solver path entirely.","If you must use IAC, reference it only in value position (`T::C`), never in a type-projection or alias context.","Gate IAC usage behind `#![feature(inherent_associated_types)]` and test on the exact nightly that supports it."],"tags":["rustc","trait-solver","next-solver","ice","inherent-associated-types","inherent-associated-const"],"analyzedSha":"22057b88b091743bc0fd8d592a9264f0a6951403","analyzedAt":"2026-08-03T08:09:25.915Z","schemaVersion":2}