rust-lang/rust · critical

expected monomorphic const in codegen

Error message

expected monomorphic const in codegen

What it means

This fires in Cranelift codegen's debug info generation for `ty::Array(elem_ty, len)`. The array length const is resolved via `len.try_to_target_usize(tcx).expect("expected monomorphic const in codegen")`. By codegen time, the array length should be a concrete usize. If it's still generic or unevaluated, this panics. Same monomorphization invariant as [270] and [272], but in the debug-info type-emit path.

Source

Thrown at compiler/rustc_codegen_cranelift/src/debuginfo/types.rs:47

        tcx: TyCtxt<'tcx>,
        type_dbg: &mut TypeDebugContext<'tcx>,
        ty: Ty<'tcx>,
    ) -> UnitEntryId {
        if let Some(&type_id) = type_dbg.type_map.get(&ty) {
            return type_id;
        }

        let type_id = match ty.kind() {
            ty::Never | ty::Bool | ty::Char | ty::Int(_) | ty::Uint(_) | ty::Float(_) => {
                self.basic_type(tcx, ty)
            }
            ty::Tuple(elems) if elems.is_empty() => self.basic_type(tcx, ty),
            ty::Array(elem_ty, len) => self.array_type(
                tcx,
                type_dbg,
                ty,
                *elem_ty,
                len.try_to_target_usize(tcx).expect("expected monomorphic const in codegen"),
            ),
            // ty::Slice(_) | ty::Str
            // ty::Dynamic
            // ty::Foreign
            ty::RawPtr(pointee_type, _) | ty::Ref(_, pointee_type, _) => {
                self.pointer_type(tcx, type_dbg, ty, *pointee_type)
            }
            // ty::Adt(def, args) if def.is_box() && args.get(1).map_or(true, |arg| cx.layout_of(arg.expect_ty()).is_1zst())
            // ty::FnDef(..) | ty::FnPtr(..)
            // ty::Closure(..)
            // ty::Adt(def, ..)
            ty::Tuple(components) => self.tuple_type(tcx, type_dbg, ty, components),
            // ty::Param(_)
            // FIXME implement remaining types and add unreachable!() to the fallback branch
            _ => self.placeholder_for_type(tcx, type_dbg, ty),
        };

        type_dbg.type_map.insert(ty, type_id);

View on GitHub (pinned to 7088e4b63a)

Solutions

  1. Disable debug info: compile with `-Cdebuginfo=0` or no `-g` flag.
  2. Avoid generic const array lengths in code compiled with debug info.
  3. File an ICE bug report — the const should be monomorphized regardless of debug info.
  4. Update nightly — the debuginfo codegen path may be fixed to handle this.
  5. Try the LLVM backend to determine if this is cg_clif-specific.

Example fix

# before (debug info + generic array length → panic)
RUSTFLAGS='-Cdebuginfo=2' cargo build

# after (disable debug info to avoid the debug_type path)
RUSTFLAGS='-Cdebuginfo=0' cargo build
Defensive patterns

Strategy: validation

Validate before calling

// Check that debug info is disabled when compiling generic array code
// with cg_clif:
// In .cargo/config.toml:
// [build]
// rustflags = ["-Cdebuginfo=0"]
// Or in CI:
// export RUSTFLAGS='-Cdebuginfo=0'

Prevention

When it happens

Trigger: Generating debug info (`-g` / `-Cdebuginfo=2`) for a function containing an array with a generic or unevaluated const length. The type-debug context tries to emit the DWARF array type with its length, but the const isn't monomorphized.

Common situations: Compiling with debug info enabled on code using generic const array lengths (`[T; N]`). The type-debug path (`debug_type`) is only hit when emitting debug info, so this is specifically a debug-info-enabled compilation issue. Can be avoided by disabling debug info as a workaround.

Related errors


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