rust-lang/rust · error

internal error: entered unreachable code

Error message

internal error: entered unreachable code

What it means

In get_fn, the branch where cx.get_declared_value(sym) returns Some is marked unreachable!(). The inline comment explains that get_declared_value only ever returns global variables, never functions, so a function symbol already being declared is assumed impossible. Reaching the panic indicates state corruption: a function symbol was registered in the globals map, or two distinct monomorphization Instances collided on the same symbol name.

Source

Thrown at compiler/rustc_codegen_gcc/src/callee.rs:34

/// - `instance`: the instance to be instantiated
pub fn get_fn<'gcc, 'tcx>(cx: &CodegenCx<'gcc, 'tcx>, instance: Instance<'tcx>) -> Function<'gcc> {
    let tcx = cx.tcx();

    assert!(!instance.args.has_infer());
    assert!(!instance.args.has_escaping_bound_vars());

    let sym = tcx.symbol_name(instance).name;

    if let Some(&func) = cx.function_instances.borrow().get(&instance) {
        return func;
    }

    let fn_abi = cx.fn_abi_of_instance(instance, ty::List::empty());

    let func = if let Some(_func) = cx.get_declared_value(sym) {
        // FIXME(antoyo): we never reach this because get_declared_value only returns global variables
        // and here we try to get a function.
        unreachable!();
        /*
        // Create a fn pointer with the new signature.
        let ptrtype = fn_abi.ptr_to_gcc_type(cx);

        // This is subtle and surprising, but sometimes we have to bitcast
        // the resulting fn pointer.  The reason has to do with external
        // functions.  If you have two crates that both bind the same C
        // library, they may not use precisely the same types: for
        // example, they will probably each declare their own structs,
        // which are distinct types from LLVM's point of view (nominal
        // types).
        //
        // Now, if those two crates are linked into an application, and
        // they contain inlined code, you can wind up with a situation
        // where both of those functions wind up being loaded into this
        // application simultaneously. In that case, the same function
        // (from LLVM's point of view) requires two types. But of course
        // LLVM won't allow one function to have two types.

View on GitHub (pinned to 22057b88b0)

Solutions

1. Search the dependency graph for duplicate #[no_mangle] / #[export_name] definitions producing the same symbol and rename one.
2. Run cargo clean and rebuild to rule out stale incremental artifacts corrupting the symbol/instance map.
3. Update rustc_codegen_gcc — this is a long-standing FIXME that may be fixed in newer versions.
4. Reduce the failing crate to a minimal reproducer and file an issue with the symbol name printed in the panic context.

Example fix

// before (two crates, same symbol)
#[no_mangle]
pub extern "C" fn init() { /* ... */ }

// after
#[no_mangle]
pub extern "C" fn mycrate_init() { /* ... */ }

// Internal invariant: a function symbol must not already be registered as a
// global when get_fn is called. Validate your symbol table before codegen:
if cx.get_declared_value(sym).is_some() {
    // Symbol was pre-registered as a global; clear or rename before get_fn.
    return /* existing function handle or error */;
}

fn symbol_is_safe_for_get_fn<'gcc>(cx: &CodegenCx<'gcc, '_>, sym: &str) -> bool {
    cx.get_declared_value(sym).is_none()
}

let r = std::panic::catch_unwind(std::panic::AssertUnwindSafe(|| {
    callee::get_fn(cx, instance)
}));
match r {
    Ok(f) => f,
    Err(_) => {
        // Fallback: re-declare via declare_fn with a fresh symbol suffix.
        cx.declare_fn(&format!("{sym}_retry"), fn_abi)
    }
}

When it happens

Trigger: Two Instance values produce identical tcx.symbol_name strings but different types, causing the second to hit the already-declared path; or a function symbol was incorrectly inserted via declare_global / get_declared_value elsewhere in the backend.

Common situations: Duplicate #[no_mangle] or #[export_name] on functions across crates that get linked together; generic functions instantiated identically across crates producing colliding symbols; -C prefer-dynamic interactions; stale incremental compilation artifacts (cargo cache) that confuse the function_instances map.

Related errors

• unsupported integer: {self:?}
• unsupported float: {self:?}
• ptr_sized_integer: unknown pointer bit size {bits}
• prologue for {:?}
• epilogue for {:?}

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