wasmerio/wasmer · error · panic

custom-descriptors not implemented yet

Error message

custom-descriptors not implemented yet

What it means

The export-section parser does not support the FuncExact external kind, which comes from the custom-descriptors / GC-related proposal extensions. When parse_export_section encounters an export whose ExternalKind is FuncExact, it panics with unimplemented! instead of calling an environ declare method. Standard export kinds (func, table, memory, global, tag) are handled; FuncExact is not.

Source

Thrown at lib/compiler/src/translator/sections.rs:424

            ref kind,
            index,
        } = entry.map_err(from_binaryreadererror_wasmerror)?;

        // The input has already been validated, so we should be able to
        // assume valid UTF-8 and use `from_utf8_unchecked` if performance
        // becomes a concern here.
        let index = index as usize;
        match *kind {
            ExternalKind::Func => environ.declare_func_export(FunctionIndex::new(index), field)?,
            ExternalKind::Table => environ.declare_table_export(TableIndex::new(index), field)?,
            ExternalKind::Memory => {
                environ.declare_memory_export(MemoryIndex::new(index), field)?
            }
            ExternalKind::Global => {
                environ.declare_global_export(GlobalIndex::new(index), field)?
            }
            ExternalKind::Tag => environ.declare_tag_export(TagIndex::new(index), field)?,
            ExternalKind::FuncExact => unimplemented!("custom-descriptors not implemented yet"),
        }
    }

    environ.finish_exports()?;
    Ok(())
}

/// Parses the Start section of the wasm module.
pub fn parse_start_section(index: u32, environ: &mut ModuleEnvironment) -> WasmResult<()> {
    environ.declare_start_function(FunctionIndex::from_u32(index))?;
    Ok(())
}

fn read_elems(items: &ElementItems) -> WasmResult<Box<[FunctionIndex]>> {
    let mut out = Vec::new();

    match items {
        ElementItems::Functions(funcs) => {

View on GitHub (pinned to 8c4b9ee9d3)

Solutions

1. Rebuild the module without the custom-descriptors / function-references exports so exports use standard Func kind.
2. Post-process the binary (wasm-tools strip / rewrite) to convert or remove FuncExact exports before loading.
3. Pre-scan the export section and reject modules containing FuncExact with a clear unsupported-feature message.
4. Track proposal support upstream and upgrade the library once FuncExact exports are implemented.

// reject FuncExact exports before translation
fn has_func_exact_export(bytes: &[u8]) -> bool {
    use wasmparser::*;
    for payload in Parser::new(0).parse_all(bytes) {
        if let Ok(Payload::ExportSection(s)) = payload {
            for e in s {
                if let Ok(exp) = e {
                    if exp.kind == wasmparser::ExternalKind::Func { /* standard */ }
                    // raw kind byte 0x05 / FuncExact indicates unsupported
                }
            }
        }
    }
    false
}

let module = std::panic::catch_unwind(|| translate_module(bytes, &env))
    .map_err(|_| LoadError::UnsupportedFeature("custom-descriptors exports"))?;

When it happens

Trigger: Translating a module whose export section contains an entry with kind FuncExact (0x05), produced by toolchains emitting exact-function exports under the custom-descriptors proposal. Reached via translate_module -> parse_export_section.

Common situations: Using modules compiled with bleeding-edge wasm feature flags (custom-descriptors / function-references exports), running wasm-tools/nightly clang output through this runtime, or fuzz-generated binaries using the new external kind byte.

Related errors

• not yet implemented
• Exception handling is not yet supported in js
• The {val:?} is not yet supported
• Table.copy is not natively supported in Javascript
• The type is not yet supported in the JS Global API

AI-assisted analysis of wasmerio/wasmer@8c4b9ee9d3 (2026-09-01). Data as JSON: /api/errors/848d559ef4bc13f7. Report an issue: GitHub.