ICE: `could not replace AliasTerm` on stable when a `dyn Fn*`-supertrait object's signature uses a `const`-length array

[MarijnS95]

Note

Authors' note: this report was generated with Claude, that quickly reduced a 4-line repro from a massive many-crate repository. It is a regression to us in the 1.96 -> 1.97.0/.1 upgrade. It compiles fine under rustc +1.96.0 --crate-type lib ice.rs.

Code

Compiles with rustc --crate-type lib ice.rs (no flags needed — happens on the default solver on stable, because vtable-slot resolution invokes the next solver internally):

const N: usize = 6;
pub trait CustomPassFn: FnOnce(&[u32; N]) {}
impl<F: FnOnce(&[u32; N])> CustomPassFn for F {}
pub fn run(f: Box<dyn CustomPassFn>, b: &[u32; N]) { f(b) }

Bisecting the ingredients:

• Required: the array length is a named const ([u32; N]). Replacing N with the literal 6 compiles fine.
• Required: the boxed dyn CustomPassFn is actually called (f(b)), forcing vtable-slot resolution.

This looks like the same family as #155761 and #155035, but those use associated-type / nested-dyn triggers and require -Znext-solver explicitly. This variant reproduces on stable with the default solver and no flags, triggered by a const-length array in the Fn signature.

Meta

rustc --version --verbose:

rustc 1.97.1 (8bab26f4f 2026-07-14)
host: aarch64-apple-darwin

Also reproduces on editions 2015, 2021, and 2024.

Error output

thread 'rustc' panicked at compiler/rustc_next_trait_solver/src/solve/assembly/structural_traits.rs:1005:13:
could not replace AliasTerm { args: [dyn [.. Trait(CustomPassFn) .., Projection(ExistentialProjection {
def_id: ..core::ops::function::FnOnce::Output, args: [(&'^0 [u32; 6_usize])], term: Term::Ty(()), .. })] + '!0,
(&'?3 [u32; UnevaluatedConst { def: ..CustomPassFn::{constant#0}, args: [] }])], kind: ProjectionTy {
def_id: ..core::ops::function::FnOnce::Output }, .. } with term from ...

Backtrace

   2: <rustc_next_trait_solver::solve::assembly::structural_traits::ReplaceProjectionWith<..>>::try_eagerly_replace_alias
   5: rustc_next_trait_solver::solve::assembly::structural_traits::predicates_for_object_candidate::<..>
   6: <..TraitPredicate<..> as ..GoalKind<..>>::match_assumption::<..probe_and_consider_object_bound_candidate..>
   8: <..EvalCtxt<..>>::compute_trait_goal
  15: <..FulfillmentCtxt<..> as ..TraitEngine<..>>::try_evaluate_obligations
  16: rustc_trait_selection::traits::impossible_predicates
  17: rustc_trait_selection::traits::instantiate_and_check_impossible_predicates
  18: rustc_trait_selection::traits::vtable::first_method_vtable_slot
  20: rustc_ty_utils::instance::resolve_instance_raw
  23: <..MirUsedCollector as ..Visitor>::visit_terminator
  24: rustc_monomorphize::collector::items_of_instance

Query stack:

#0 [instantiate_and_check_impossible_predicates] checking impossible instantiated predicates: `CustomPassFn`
#1 [first_method_vtable_slot] finding the slot within the vtable of `dyn CustomPassFn<Output = ()>` for the implementation of `core::ops::function::FnOnce`

[maxdexh]

You also need to invoke the function.

const N: usize = 6;
pub trait CustomPassFn: FnOnce(&[u32; N]) {}
impl<F: FnOnce(&[u32; N])> CustomPassFn for F {}
pub fn run(f: Box<dyn CustomPassFn>, b: &[u32; N]) {
    f(b)
}
fn main() {
    run(Box::new(|_| {}), &[0; _])
}

@rustbot label regression-from-stable-to-stable I-ICE C-Bug

[maxdexh]

Potentially the same issue as #159462? (this one was first, so I'm not calling it a duplicate)

[workingjubilee]

@MarijnS95 Yo, what's your setup for Claude that it gave you this bug report? Or how hand-edited was it?

Usually such tools give us reports that are more... "sounds smart/impressive but isn't actually good/useful".

[chenyukang]

I bisec and found it should be introduced by #156246

cc @jdonszelmann

[maxdexh]

Interesting, that's not the same as the bisection result from #159462.

Fun coincidence? ^^