What causes "Pointee is not const" in rust-lang/rust?

Remove any const/host-effect bound that could force a `const Pointee` obligation.

Pointee is not const

Error message

Pointee is not const

What it means

`consider_builtin_pointee_candidate` (effect_goals.rs:371) is `unreachable!`. The `Pointee` built-in trait (used to derive the metadata/pointee type for `std::ptr::Pointee`) has no const counterpart — querying `T: const Pointee` is logically invalid. Reaching this branch indicates the host-effect goal assembly produced a goal that should have been filtered out earlier.

Source

Thrown at compiler/rustc_next_trait_solver/src/solve/effect_goals.rs:371

    fn consider_builtin_async_fn_kind_helper_candidate(
        _ecx: &mut EvalCtxt<'_, D>,
        _goal: Goal<I, Self>,
    ) -> Result<Candidate<I>, NoSolutionOrRerunNonErased> {
        unreachable!("AsyncFnKindHelper is not const")
    }

    fn consider_builtin_tuple_candidate(
        _ecx: &mut EvalCtxt<'_, D>,
        _goal: Goal<I, Self>,
    ) -> Result<Candidate<I>, NoSolutionOrRerunNonErased> {
        unreachable!("Tuple trait is not const")
    }

    fn consider_builtin_pointee_candidate(
        _ecx: &mut EvalCtxt<'_, D>,
        _goal: Goal<I, Self>,
    ) -> Result<Candidate<I>, NoSolutionOrRerunNonErased> {
        unreachable!("Pointee is not const")
    }

    fn consider_builtin_future_candidate(
        _ecx: &mut EvalCtxt<'_, D>,
        _goal: Goal<I, Self>,
    ) -> Result<Candidate<I>, NoSolutionOrRerunNonErased> {
        unreachable!("Future is not const")
    }

    fn consider_builtin_iterator_candidate(
        _ecx: &mut EvalCtxt<'_, D>,
        _goal: Goal<I, Self>,
    ) -> Result<Candidate<I>, NoSolutionOrRerunNonErased> {
        Err(NoSolutionOrRerunNonErased::NoSolution(NoSolution))
    }

    fn consider_builtin_fused_iterator_candidate(
        _ecx: &mut EvalCtxt<'_, D>,

View on GitHub (pinned to 22057b88b0)

Solutions

Remove any const/host-effect bound that could force a `const Pointee` obligation.
Disable `-Znext-solver` and `const_trait_impl` to confirm the source.
Reduce and report the ICE; upgrade nightly.
Avoid `Pointee`-dependent generic code inside `const fn` boundaries.

Defensive patterns

Strategy: validation

Validate before calling

// Pointee (the trait behind `core::ptr::Pointee`) is not const. Do not request a Pointee
// metadata computation (e.g. slice/dyn metadata) inside a const obligation.
const fn reject_pointee_in_const<T: ?Sized>(_t: &T) {} // ICE if next solver evaluates Pointee

Type guard

// Narrow to sized types so Pointee metadata is trivial and never solved in const.
fn sized_only<T: Sized>(_t: &T) {}

Prevention

Avoid `core::ptr::Pointee` / `Pointee::Metadata` lookups in `const fn` or const generics; the trait is non-const.
For unsized types in const code, compute metadata via concrete intrinsic (e.g. `slice.len()`) rather than the Pointee trait.
Bound const generic params with `T: Sized` to keep the solver away from Pointee entirely.

When it happens

Trigger: Reached when the next solver evaluates a `HostEffectPredicate` for the `Pointee` trait (lang item) with a const effect and falls into the built-in pointee candidate branch (effect_goals.rs:367).

Common situations: Nightly with `const_trait_impl`/`host_effects` combined with custom DSTs / `std::ptr::Pointee` usage; solver refactor that no longer short-circuits unsatisfiable host-effect goals; goal emitted via a derive or generic bound.

Related errors

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