{"id":"aa5fe76f2450d488","repo":"rust-lang/rust","slug":"internal-error-entered-unreachable-code-aa5fe7","errorCode":null,"errorMessage":"internal error: entered unreachable code","messagePattern":"internal error: entered unreachable code","errorType":"panic","errorClass":null,"httpStatus":null,"severity":"error","filePath":"compiler/rustc_codegen_gcc/src/callee.rs","lineNumber":34,"sourceCode":"/// - `instance`: the instance to be instantiated\npub fn get_fn<'gcc, 'tcx>(cx: &CodegenCx<'gcc, 'tcx>, instance: Instance<'tcx>) -> Function<'gcc> {\n    let tcx = cx.tcx();\n\n    assert!(!instance.args.has_infer());\n    assert!(!instance.args.has_escaping_bound_vars());\n\n    let sym = tcx.symbol_name(instance).name;\n\n    if let Some(&func) = cx.function_instances.borrow().get(&instance) {\n        return func;\n    }\n\n    let fn_abi = cx.fn_abi_of_instance(instance, ty::List::empty());\n\n    let func = if let Some(_func) = cx.get_declared_value(sym) {\n        // FIXME(antoyo): we never reach this because get_declared_value only returns global variables\n        // and here we try to get a function.\n        unreachable!();\n        /*\n        // Create a fn pointer with the new signature.\n        let ptrtype = fn_abi.ptr_to_gcc_type(cx);\n\n        // This is subtle and surprising, but sometimes we have to bitcast\n        // the resulting fn pointer.  The reason has to do with external\n        // functions.  If you have two crates that both bind the same C\n        // library, they may not use precisely the same types: for\n        // example, they will probably each declare their own structs,\n        // which are distinct types from LLVM's point of view (nominal\n        // types).\n        //\n        // Now, if those two crates are linked into an application, and\n        // they contain inlined code, you can wind up with a situation\n        // where both of those functions wind up being loaded into this\n        // application simultaneously. In that case, the same function\n        // (from LLVM's point of view) requires two types. But of course\n        // LLVM won't allow one function to have two types.","sourceCodeStart":16,"sourceCodeEnd":52,"githubUrl":"https://github.com/rust-lang/rust/blob/22057b88b091743bc0fd8d592a9264f0a6951403/compiler/rustc_codegen_gcc/src/callee.rs#L16-L52","documentation":"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.","triggerScenarios":"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.","commonSituations":"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.","solutions":["Search the dependency graph for duplicate #[no_mangle] / #[export_name] definitions producing the same symbol and rename one.","Run cargo clean and rebuild to rule out stale incremental artifacts corrupting the symbol/instance map.","Update rustc_codegen_gcc — this is a long-standing FIXME that may be fixed in newer versions.","Reduce the failing crate to a minimal reproducer and file an issue with the symbol name printed in the panic context."],"exampleFix":"// before (two crates, same symbol)\n#[no_mangle]\npub extern \"C\" fn init() { /* ... */ }\n\n// after\n#[no_mangle]\npub extern \"C\" fn mycrate_init() { /* ... */ }","handlingStrategy":"fallback","validationCode":"// Internal invariant: a function symbol must not already be registered as a\n// global when get_fn is called. Validate your symbol table before codegen:\nif cx.get_declared_value(sym).is_some() {\n    // Symbol was pre-registered as a global; clear or rename before get_fn.\n    return /* existing function handle or error */;\n}","typeGuard":"fn symbol_is_safe_for_get_fn<'gcc>(cx: &CodegenCx<'gcc, '_>, sym: &str) -> bool {\n    cx.get_declared_value(sym).is_none()\n}","tryCatchPattern":"let r = std::panic::catch_unwind(std::panic::AssertUnwindSafe(|| {\n    callee::get_fn(cx, instance)\n}));\nmatch r {\n    Ok(f) => f,\n    Err(_) => {\n        // Fallback: re-declare via declare_fn with a fresh symbol suffix.\n        cx.declare_fn(&format!(\"{sym}_retry\"), fn_abi)\n    }\n}","preventionTips":["Do not pre-register function names as globals; get_declared_value must return None for fn symbols.","Namespace statics and functions apart (different symbol prefixes) so they cannot collide in the declared-value map.","If you maintain your own symbol cache, invalidate entries that get re-classified from global to function.","Treat this panic as a bug in symbol bookkeeping — report it upstream with the colliding symbol name."],"tags":["symbols","monomorphization","codegen","rustc"],"analyzedSha":"22057b88b091743bc0fd8d592a9264f0a6951403","analyzedAt":"2026-08-03T08:09:25.915Z","schemaVersion":2}