wasmerio/wasmer · error

not yet implemented

Error message

not yet implemented

What it means

`type_to_wp_type` in the singlepass compiler converts internal wasm `Type` values to stack-machine `WpType` values; the `Type::ExceptionRef` arm is a `todo!()`. Compiling a module that uses exception-reference types on the operand stack panics with 'not yet implemented', because singlepass does not yet support the exception-handling (exnref) proposal.

Source

Thrown at lib/compiler-singlepass/src/codegen.rs:268

    }

    /// Returns the value stack depth at which resources should be deallocated.
    /// For loops, this preserves PHI arguments by excluding them from deallocation.
    fn value_stack_depth_for_release(&self) -> usize {
        self.value_stack_depth - self.param_types.len()
    }
}

fn type_to_wp_type(ty: &Type) -> WpType {
    match ty {
        Type::I32 => WpType::I32,
        Type::I64 => WpType::I64,
        Type::F32 => WpType::F32,
        Type::F64 => WpType::F64,
        Type::V128 => WpType::V128,
        Type::ExternRef => WpType::Ref(WpRefType::new(true, WpHeapType::EXTERN).unwrap()),
        Type::FuncRef => WpType::Ref(WpRefType::new(true, WpHeapType::FUNC).unwrap()),
        Type::ExceptionRef => todo!(),
    }
}

/// Abstraction for a 2-input, 1-output operator. Can be an integer/floating-point
/// binop/cmpop.
struct I2O1<R: Reg, S: Reg> {
    loc_a: Location<R, S>,
    loc_b: Location<R, S>,
    ret: Location<R, S>,
}

/// Type of native call we emit.
enum NativeCallType {
    IncludeVMCtxArgument,
    Unreachable,
}

const RED_ZONE_SIZE: usize = 32;

View on GitHub (pinned to 8c4b9ee9d3)

Solutions

1. Compile the module without exception-handling (e.g. rebuild wasm with legacy EH or without --enable-exceptions)
2. Use the Cranelift compiler instead of singlepass if your platform allows it
3. Upgrade wasmtime to a version with exnref support in singlepass
4. Disable the exceptions feature in the wasm toolchain/runtime config

Example fix

// before: singlepass panics on exnref
let mut config = Config::new();
config.strategy(Strategy::Winch); // or default singlepass on RISC-V
config.wasm_exceptions(true);
// after: use Cranelift or disable exceptions
let mut config = Config::new();
config.strategy(Strategy::Cranelift); // exnref supported here
// or: config.wasm_exceptions(false);

// Reject exnref-typed modules before singlepass compilation.
let mut features = WasmFeatures::default();
features.exceptions = false;
wasmparser::Validator::new_with_features(features).validate_all(&wasm_bytes)?;
// or check config: if compiling with singlepass, ensure exceptions disabled
let mut config = Config::new();
config.wasm_exceptions(false);

fn supports_backend(ty: &Type) -> bool {
    !matches!(ty, Type::ExceptionRef)
}

When it happens

Trigger: Compiling a wasm module with exception handling enabled where an `exnref`-typed value must be mapped to a WpType; reached from `feed_operator` -> `type_to_wp_type` at codegen.rs:268.

Common situations: Modules built with the WebAssembly exception-handling proposal (try/catch, throw with exnref operands) run through wasmtime's singlepass backend (often used with -O0 or on platforms Cranelift does not cover).

Related errors

• not yet implemented
• Symbol {} in DWARF not recognized
• internal error: entered unreachable code
• unsupported location
• not yet implemented

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