Stream: git-wasmtime

Topic: wasmtime / issue #13976 component::Instance: expose core ...

Wasmtime GitHub notifications bot (Jul 25 2026 at 10:47):

zacharywhitley opened issue #13976:

Request: expose core exports of internal core instances on wasmtime::component::Instance

Use case. A component whose underlying core module exposes a raw core export used for re-entrancy (host builds a callback → guest invokes callback → callback body re-enters the guest via a raw core export like wasmcm_dispatch_host_func). This is the same pattern the WASI-preview1 adapter's cabi_realloc uses at the boundary, but for a runtime-guest-defined helper rather than an ABI helper.

Today wasmtime::component::Instance's public surface (get_func / get_typed_func / get_module / get_resource / get_export / get_export_index) reaches only WIT-lifted exports. The underlying pub(crate) fn lookup_vmexport at crates/wasmtime/src/runtime/component/instance.rs:620 already provides the machinery — this request is a small public bridge.

Proposed signature (open to shape guidance):

impl Instance {
    /// Access a core-level export of one of this component's internal core
    /// module instances by name. Returns `None` if the instance index or the
    /// name doesn't resolve, or if the export isn't representable as
    /// `Extern`.
    ///
    /// This is a low-level escape hatch for hosts that need to bind re-
    /// entrancy paths through a guest's raw core exports. Most consumers
    /// should prefer `get_func` / `get_typed_func` against WIT-lifted
    /// exports.
    pub fn get_core_export(
        &self,
        mut store: impl AsContextMut,
        instance_index: RuntimeInstanceIndex,
        name: &str,
    ) -> Option<Extern>;
}

Happy to iterate on the shape — the internal lookup_vmexport signature suggests the essentials are (store, instance_id, name); the outer wrapper's exact type of instance_index and whether name should be an ExportItem at the public boundary are calls maintainers may want to make differently.

Context (only if useful): the concrete consumer is wasmcm (portable Component-Model implementation targeting core-only engines). Its runtime-guest is componentized via wasm-tools component new; the outer host, when consumed through wasmtime's Component API, can't reach the wasmcm_dispatch_host_func core export the guest uses for host-callback re-entrancy. Bindgen-driven paths on other engines (Chicory + hand-implemented WIT imports at the core level, or wasmtime's own core Linker::func_wrap with WIT-namespaced module names) reach it fine because they operate at the core-instance level. Only wasmtime's Component-API path is bounded.

Not blocking real users; the workaround is to consume via wasmtime::Linker instead of wasmtime::component::Linker. Filing because the machinery already exists internally and a small public bridge helps any other consumer in the same shape.

Wasmtime GitHub notifications bot (Jul 27 2026 at 17:55):

alexcrichton closed issue #13976:

Request: expose core exports of internal core instances on wasmtime::component::Instance

Use case. A component whose underlying core module exposes a raw core export used for re-entrancy (host builds a callback → guest invokes callback → callback body re-enters the guest via a raw core export like wasmcm_dispatch_host_func). This is the same pattern the WASI-preview1 adapter's cabi_realloc uses at the boundary, but for a runtime-guest-defined helper rather than an ABI helper.

Today wasmtime::component::Instance's public surface (get_func / get_typed_func / get_module / get_resource / get_export / get_export_index) reaches only WIT-lifted exports. The underlying pub(crate) fn lookup_vmexport at crates/wasmtime/src/runtime/component/instance.rs:620 already provides the machinery — this request is a small public bridge.

Proposed signature (open to shape guidance):

impl Instance {
    /// Access a core-level export of one of this component's internal core
    /// module instances by name. Returns `None` if the instance index or the
    /// name doesn't resolve, or if the export isn't representable as
    /// `Extern`.
    ///
    /// This is a low-level escape hatch for hosts that need to bind re-
    /// entrancy paths through a guest's raw core exports. Most consumers
    /// should prefer `get_func` / `get_typed_func` against WIT-lifted
    /// exports.
    pub fn get_core_export(
        &self,
        mut store: impl AsContextMut,
        instance_index: RuntimeInstanceIndex,
        name: &str,
    ) -> Option<Extern>;
}

Happy to iterate on the shape — the internal lookup_vmexport signature suggests the essentials are (store, instance_id, name); the outer wrapper's exact type of instance_index and whether name should be an ExportItem at the public boundary are calls maintainers may want to make differently.

Context (only if useful): the concrete consumer is wasmcm (portable Component-Model implementation targeting core-only engines). Its runtime-guest is componentized via wasm-tools component new; the outer host, when consumed through wasmtime's Component API, can't reach the wasmcm_dispatch_host_func core export the guest uses for host-callback re-entrancy. Bindgen-driven paths on other engines (Chicory + hand-implemented WIT imports at the core level, or wasmtime's own core Linker::func_wrap with WIT-namespaced module names) reach it fine because they operate at the core-instance level. Only wasmtime's Component-API path is bounded.

Not blocking real users; the workaround is to consume via wasmtime::Linker instead of wasmtime::component::Linker. Filing because the machinery already exists internally and a small public bridge helps any other consumer in the same shape.

Wasmtime GitHub notifications bot (Jul 27 2026 at 17:55):

alexcrichton commented on issue #13976:

Thanks for the report here, but this is not something that Wasmtime will support. Supporting an API such as this would violate foundational semantic properties of the component model. Supporting components in an engine that doesn't want to implement full component model support is a bit of a broader discussion than just this API for Wasmtime itself, and if you're interested in pushing on that I'd recommend opening an issue on the WebAssembly/component-model repository

Wasmtime GitHub notifications bot (Jul 27 2026 at 18:36):

zacharywhitley commented on issue #13976:

Will do. Thanks for the feedback. "Supporting components in an engine that doesn't want to implement full component model" is exactly what I'm doing, although "don't want too" might be a bit harsh. I'd say they're reluctant participants.

Last updated: Jul 29 2026 at 05:03 UTC