rust-lang/rust · error

not implemented

Error message

not implemented

What it means

Raised by rustc_codegen_gcc's global_linkage_to_gcc when a global has Linkage::LinkOnceAny. The GCC backend maps most LLVM linkage kinds to gccjit GlobalKind values but has not implemented the link-once family, so the corresponding match arm panics with unimplemented!().

Source

Thrown at compiler/rustc_codegen_gcc/src/base.rs:48

        Visibility::Hidden => gccjit::Visibility::Hidden,
        Visibility::Protected => gccjit::Visibility::Protected,
    }
}

#[cfg(feature = "master")]
pub fn symbol_visibility_to_gcc(visibility: SymbolVisibility) -> gccjit::Visibility {
    match visibility {
        SymbolVisibility::Hidden => gccjit::Visibility::Hidden,
        SymbolVisibility::Protected => gccjit::Visibility::Protected,
        SymbolVisibility::Interposable => gccjit::Visibility::Default,
    }
}

pub fn global_linkage_to_gcc(linkage: Linkage) -> GlobalKind {
    match linkage {
        Linkage::External => GlobalKind::Imported,
        Linkage::AvailableExternally => GlobalKind::Imported,
        Linkage::LinkOnceAny => unimplemented!(),
        Linkage::LinkOnceODR => unimplemented!(),
        Linkage::WeakAny => unimplemented!(),
        Linkage::WeakODR => unimplemented!(),
        Linkage::Internal => GlobalKind::Internal,
        Linkage::ExternalWeak => GlobalKind::Imported, // FIXME(antoyo): should be weak linkage.
        Linkage::Common => unimplemented!(),
    }
}

pub fn linkage_to_gcc(linkage: Linkage) -> FunctionType {
    match linkage {
        Linkage::External => FunctionType::Exported,
        // FIXME(antoyo): set the attribute externally_visible.
        Linkage::AvailableExternally => FunctionType::Extern,
        Linkage::LinkOnceAny => unimplemented!(),
        Linkage::LinkOnceODR => unimplemented!(),
        Linkage::WeakAny => FunctionType::Exported, // FIXME(antoyo): should be similar to linkonce.
        Linkage::WeakODR => unimplemented!(),

View on GitHub (pinned to 7088e4b63a)

Solutions

1. Map LinkOnceAny to an equivalent gccjit GlobalKind (Internal or Imported) as a downstream patch and verify ABI.
2. Avoid the code pattern that forces link-once linkage (e.g. avoid the crate/generic that monomorphizes into a link-once global).
3. Track upstream rustc_codegen_gcc issue for linkage coverage.

Example fix

// before
Linkage::LinkOnceAny => unimplemented!(),
// after (downstream patch, verify ABI correctness)
Linkage::LinkOnceAny => GlobalKind::Imported,

// Before relying on the GCC backend, confirm no global uses LinkOnceAny linkage
// e.g. dump the crate and grep for linkonce symbols:
// rustc --emit metadata crate.rs && inspect symbols for linkonce_any

fn is_supported_global_linkage(l: Linkage) -> bool {
    matches!(l, Linkage::External | Linkage::AvailableExternally
             | Linkage::Internal | Linkage::ExternalWeak | Linkage::Common)
}

When it happens

Trigger: Compiling code under the GCC backend where a global/static symbol is assigned LinkOnceAny linkage (typically COMDAT-like or template-instantiation globals emitted by upstream rustc). global_linkage_to_gcc at base.rs:48 panics.

Common situations: Cross-crate generics or monomorphization emit link-once globals; a codegen change in rustc starts emitting LinkOnceAny for a construct the GCC backend previously never saw; building std/core with the GCC backend.

Related errors

• from rlib
• from uncompressed file
• not implemented
• archive member at offset {start} with size {} exceeds archiv
• {context}: {err}

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