rust-lang/rust · critical

TransmuteFrom is not const

Error message

TransmuteFrom is not const

What it means

Internal `unreachable!` in the next-gen trait solver's const-effect candidate assembly for the built-in `TransmuteFrom` trait (`core::mem::TransmuteFrom`, the safe-transmute trait). Safe transmute has no const implementation, so `consider_builtin_transmute_candidate` exists only to satisfy the `GoalKind` interface and is never expected to run. Reaching it ICEs the compiler.

Source

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

            ecx.add_goals(
                GoalSource::AliasBoundConstCondition,
                const_conditions.into_iter().map(|trait_ref| {
                    goal.with(
                        cx,
                        ty::Binder::dummy(trait_ref)
                            .to_host_effect_clause(cx, goal.predicate.constness),
                    )
                }),
            )?;
            ecx.evaluate_added_goals_and_make_canonical_response(Certainty::Yes)
        })
    }

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

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

    fn consider_builtin_try_as_dyn_candidate(
        _ecx: &mut EvalCtxt<'_, D>,
        goal: Goal<I, Self>,
    ) -> Result<Candidate<I>, NoSolutionOrRerunNonErased> {
        unreachable!("`TryAsDynCompat` is not const: {:?}", goal)
    }

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

View on GitHub (pinned to 22057b88b0)

Solutions

  1. Do not put a const bound on `TransmuteFrom`; transmutation is not const-evaluable.
  2. Hoist the transmute out of the `const fn` into runtime code, or precompute the value as a `static`/`const` of the target type.
  3. Report the ICE upstream with a minimal reproducer (include `-Znext-solver` and the safe-transmute feature gate).
  4. Bisect the nightly toolchain; transmute const routing is under active development.

Example fix

// before
const fn reinterpret<U, T: const TransmuteFrom<U>>(u: U) -> T { unsafe { transmute(u) } }

// after — compute at runtime
fn reinterpret<U, T: TransmuteFrom<U>>(u: U) -> T { u.transmute_into() }
Defensive patterns

Strategy: validation

Validate before calling

// build.rs: reject const TransmuteFrom (safe transmute) bounds
fn main() {
    let src = std::fs::read_to_string("src/lib.rs").unwrap_or_default();
    for banned in ["~const TransmuteFrom", "const TransmuteFrom", "const core::mem::TransmuteFrom"] {
        assert!(!src.contains(banned), "rejected: {banned} — TransmuteFrom has no const impl");
    }
    println!("cargo:rerun-if-changed=src/lib.rs");
}

Prevention

When it happens

Trigger: A host-effect goal resolves to the `TransmuteFrom` lang item: code that requires `T: const TransmuteFrom<U>` / `~const TransmuteFrom<U>`, or that calls `mem::transmute`/safe-transmute APIs inside a `const fn` under `-Znext-solver`, forcing the solver to probe a const transmute candidate.

Common situations: Using nightly `safe_transmute`/`mem::transmute` inside `const fn`; generic const code over bitwise-reinterpretable types; enabling `-Znext-solver` on FFI/bytebuffer code; toolchain regression after transmute effect-goal routing landed.

Related errors


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