rust-lang/rust · error

Kind: {:?}

Error message

Kind: {:?}

What it means

This unimplemented!() is the catch-all in type_kind_to_gcc_type, a free function that maps a rustc TyKind (Int/Uint variants) to a libgccjit CType. Only Int(I8..I128) and Uint(U8..U128) are handled; any other TyKind (bool/Float/Char/Adt/etc.) reaching this function triggers it. The message prints the offending kind to aid diagnosis.

Source

Thrown at compiler/rustc_codegen_gcc/src/int.rs:1064

fn type_kind_to_gcc_type<I: Interner>(kind: TyKind<I>) -> CType {
    use rustc_middle::ty::IntTy::*;
    use rustc_middle::ty::UintTy::*;
    use rustc_middle::ty::{Int, Uint};

    match kind {
        Int(I8) => CType::Int8t,
        Int(I16) => CType::Int16t,
        Int(I32) => CType::Int32t,
        Int(I64) => CType::Int64t,
        Int(I128) => CType::Int128t,

        Uint(U8) => CType::UInt8t,
        Uint(U16) => CType::UInt16t,
        Uint(U32) => CType::UInt32t,
        Uint(U64) => CType::UInt64t,
        Uint(U128) => CType::UInt128t,

        _ => unimplemented!("Kind: {:?}", kind),
    }
}

View on GitHub (pinned to 22057b88b0)

Solutions

1. Identify the caller passing the non-integer TyKind (enable debug logging of TyKind before the call) and route it through the correct type mapping for its kind.
2. Extend type_kind_to_gcc_type only if the function is genuinely meant to handle the new kind; otherwise fix the dispatch at the call site.
3. Reproduce on a clean checkout of the rustc/rustc_codegen_gcc pair to rule out a local patch introducing the bad TyKind.
4. Report upstream with the exact TyKind value printed by the message.

Example fix

// before
let ty = type_kind_to_gcc_type(kind); // kind is a bool/float/char
// after (dispatch by kind at the call site)
let ty = match kind {
    TyKind::Int(_) | TyKind::Uint(_) => type_kind_to_gcc_type(kind),
    TyKind::Bool => cx.type_i1(),
    other => panic!("unexpected tykind in this path: {:?}", other),
};

# type_kind_to_gcc_type only maps Int/Uint TyKinds; any other kind is unimplemented!.
# This is a compiler bug, not a source pattern you can reliably predict. Pre-check toolchain version:
rustc -V --verbose | rg 'release:'
# and run the crate's full test suite on the LLVM backend first; if green, the GCC panic is the backend's gap.

set +e
RUSTFLAGS='-C codegen-backend=gcc' cargo build --release 2>gcc_build.log
status=$?
set -e
if [ $status -ne 0 ]; then
  echo 'GCC backend failed (int.rs:1064 unimplemented TyKind); rebuilding with LLVM backend' >&2
  cargo build --release
  # Capture a minimal repro for the upstream bug report.
  rg -n 'rustc_codegen_gcc' gcc_build.log | head -n 20 > gcc_repro.txt
fi

When it happens

Trigger: type_kind_to_gcc_type is invoked with a TyKind that is not an integer kind (Int or Uint). This happens when a caller passes a non-integer type where an integer CType was expected, e.g. a bool, float, or char leaking into integer-only type mapping during codegen.

Common situations: Internal codegen changes that route non-integer TyKinds through type_kind_to_gcc_type; bugs where bool or float types are mapped via the integer path; refactors of the type mapping after a rustc upgrade.

Related errors

• Called extract_element on a non-vector type
• cannot cast a non-native integer to type {:?}
• cannot cast a {:?} to non-native integer
• first index in inbounds_gep
• vector type

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