`feature(generic_const_exprs)` is not supported in the new…

Error message

`feature(generic_const_exprs)` is not supported in the new trait solver

What it means

An `unimplemented!("\`feature(generic_const_exprs)\` is not supported in the new trait solver")` ICE in the next trait solver. When a const argument is a `ConstKind::Expr` (an unexpanded const expression, the representation the `generic_const_exprs` feature produces), the new solver explicitly refuses it because that feature is incompatible with the new solver and panics at mod.rs:269.

Solutions

Do not combine `-Znext-solver` with `#![feature(generic_const_exprs)]`; pick one.
Remove `generic_const_exprs` and use concrete const values or const generics that do not require expression evaluation.
Track upstream; the new solver may eventually support `generic_const_exprs`, but currently it is a hard incompatibility.

Example fix

// before (next solver + generic_const_exprs -> ICE)
#![feature(generic_const_exprs)]
fn f<const N: usize>() -> [u8; N + 1] { [0; N + 1] }
// compiled with: -Znext-solver

// after — drop the feature, or drop -Znext-solver
fn f<const N: usize>() -> [u8; N] { [0; N] }

Defensive patterns

Strategy: validation

Validate before calling

# Hard-incompatibility check: feature(generic_const_exprs) + next-solver
if rg -q 'feature(generic_const_exprs)' src/ && [[ "${RUSTFLAGS:-}" == *next-solver* ]]; then
  echo "FATAL: feature(generic_const_exprs) is not supported with -Znext-solver"; exit 1
fi

Prevention

Never combine `#![feature(generic_const_exprs)]` with `-Znext-solver`.
Add a CI guard that fails when both are set together.
Replace `[T; N + 1]`-style const expressions with concrete consts when migrating to the next solver.

When it happens

Trigger: Enabling both `-Znext-solver` and `#![feature(generic_const_exprs)]` in the same crate, so that a const generic argument is represented as `ConstKind::Expr` and reaches `compute_const_arg_has_type_goal`.

Common situations: Nightly crates that use generic const expressions (`[u8; N + 1]` in generics) and are then compiled with the next solver enabled (globally or via a downstream crate). The two are explicitly unsupported together.

Related errors

AI-assisted analysis of rust-lang/rust@7088e4b63a (2026-08-10). Data as JSON: /api/errors/44b20fd2c442912d. Report an issue: GitHub.

Appendix: source

Thrown at compiler/rustc_next_trait_solver/src/solve/mod.rs:269

        let ct_ty = match ct.kind() {
            ty::ConstKind::Infer(_) => {
                return self
                    .evaluate_added_goals_and_make_canonical_response(Certainty::AMBIGUOUS)
                    .map_err(Into::into);
            }
            ty::ConstKind::Error(_) => {
                return self
                    .evaluate_added_goals_and_make_canonical_response(Certainty::Yes)
                    .map_err(Into::into);
            }
            ty::ConstKind::Alias(ty::IsRigid::Yes, alias_const) => {
                alias_const.type_of(self.cx()).skip_norm_wip()
            }
            ty::ConstKind::Alias(ty::IsRigid::No, _) => unimplemented!(
                "non-rigid unevaluated constant for compute_const_arg_has_type_goal: {ct:?}"
            ),
            ty::ConstKind::Expr(_) => unimplemented!(
                "`feature(generic_const_exprs)` is not supported in the new trait solver"
            ),
            ty::ConstKind::Param(_) => {
                unreachable!("`ConstKind::Param` should have been canonicalized to `Placeholder`")
            }
            ty::ConstKind::Bound(_, _) => panic!("escaping bound vars in {:?}", ct),
            ty::ConstKind::Value(cv) => cv.ty(),
            ty::ConstKind::Placeholder(placeholder) => {
                placeholder.find_const_ty_from_env(goal.param_env)
            }
        };

        self.eq(goal.param_env, ct_ty, ty)?;
        self.evaluate_added_goals_and_make_canonical_response(Certainty::Yes).map_err(Into::into)
    }
}

#[derive(Debug)]

View on GitHub (pinned to 7088e4b63a)