What causes "unexpected type `{ty:?}`" in rust-lang/rust?

Report at https://github.com/rust-lang/rust/issues with the `{ty:?}` from the panic and a minimal repro.

unexpected type `{ty:?}`

Error message

unexpected type `{ty:?}`

What it means

In the trait-goal version of `consider_builtin_bikeshed_guaranteed_no_drop_candidate` (trait_goals.rs:801), the match on `self_ty.kind()` panics for `ty::Bound(..)` and `ty::Infer(TyVar | FreshTy | FreshIntTy | FreshFloatTy)`. Such escaping-bound or unresolved type variables should be handled earlier (as ambiguous or by waiting for inference); reaching this arm means a not-yet-resolved type was passed into the builtin candidate — a solver-invariant violation.

Source

Thrown at compiler/rustc_next_trait_solver/src/solve/trait_goals.rs:801

                | ty::CoroutineWitness(..) => {
                    ecx.add_goal(
                        GoalSource::ImplWhereBound,
                        goal.with(
                            cx,
                            ty::TraitRef::new(
                                cx,
                                cx.require_trait_lang_item(SolverTraitLangItem::Copy),
                                [ty],
                            ),
                        ),
                    )?;
                }

                ty::Bound(..)
                | ty::Infer(
                    ty::TyVar(_) | ty::FreshTy(_) | ty::FreshIntTy(_) | ty::FreshFloatTy(_),
                ) => {
                    panic!("unexpected type `{ty:?}`")
                }
            }

            ecx.evaluate_added_goals_and_make_canonical_response(Certainty::Yes)
        })
    }

    /// ```ignore (builtin impl example)
    /// trait Trait {
    ///     fn foo(&self);
    /// }
    /// // results in the following builtin impl
    /// impl<'a, T: Trait + 'a> Unsize<dyn Trait + 'a> for T {}
    /// ```
    fn consider_structural_builtin_unsize_candidates(
        ecx: &mut EvalCtxt<'_, D>,
        goal: Goal<I, Self>,
    ) -> Result<Vec<Candidate<I>>, RerunNonErased> {

View on GitHub (pinned to 22057b88b0)

Solutions

Report at https://github.com/rust-lang/rust/issues with the `{ty:?}` from the panic and a minimal repro.
Disable `-Znext-solver` to use the old solver which handles the ambiguous case differently.
Add explicit type annotations / turbofish to force inference before the builtin candidate runs.
`rustup update nightly` and `cargo bisect-rustc` to find the regression.

Example fix

// before — type left inferred through a drop-sensitive position
let x = some_generic(); // BikeshedGuaranteedNoDrop goal on unknown type
// after — annotate to resolve before the candidate runs
let x: MyType = some_generic::<MyType>();

Defensive patterns

Strategy: validation

Validate before calling

// The trait-goal solver encountered an unexpected type kind (not a
// nominal/generic/alias type it can reason about).
// Validate that types used in trait bounds are fully-formed:
// - concrete types, generic params, or associated-type aliases.
trait Valid {}
impl Valid for i32 {}
fn use_bound<T: Valid>() {} // generic param: OK
fn use_concrete() { use_bound::<i32>(); } // concrete: OK
// Avoid: closures, fn pointers, or foreign types in unexpected bound positions.

Type guard

// Narrow to expected type kinds before constructing a trait goal.
// In user code this means: provide concrete type annotations instead of
// letting inference pick an unusual kind.
fn with_explicit_type<T: Valid>(_: T) {}
// Call with explicit turbofish to force a known kind:
// with_explicit_type::<i32>(5);

Prevention

Provide explicit type annotations instead of relying on inference for unusual type kinds (closures, fn pointers, foreign items).
Avoid putting trait bounds on types the solver cannot normalise (raw closures, extern types).
When this ICE appears, reduce the trait bound to its simplest form and re-add constraints incrementally to isolate the offending type.

When it happens

Trigger: A `BikeshedGuaranteedNoDrop` trait goal whose self type is still a `Bound` var or an unbound `TyVar`/`Fresh*` inference variable reaches the builtin candidate during `-Znext-solver` evaluation.

Common situations: Nightly users with complex inference (generics, closures, async/coroutines, unsafe-binder) where a type variable isn't pinned before the drop-analysis builtin candidate runs; often after a rustc update or when combining `-Znext-solver` with staged inference.

Related errors

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