Stream: rust-toolchain

Topic: rust wasi interface target

Julien Vincent (May 30 2025 at 12:49):

Hi there, I am trying to figure out how to compile a wasm component in a way that uses a deterministic/locked set of wasi interfaces.

Essentially I have some world defined in wit which described import/exports for wasi 0.2.4 and I want to validate that some compiled wasm binary targets this world using wasm-tools component targets.

When I compile my component using cargo build --target wasm32-wasip2 I find that it targets either 0.2.4 or 0.2.3 depending on what the component source-code includes.

I'm struggling to figure out how to ensure the component always targets 0.2.4. Is anyone able to assist?

Lann Martin (May 30 2025 at 13:46):

Could you say more about why you want this strict check? The current behavior is intentional; you can see some discussion here and technical details here.

Julien Vincent (May 30 2025 at 13:51):

All I want really is a mechanism to validate that some wasm component binary correctly targets some world defined in a provided wit file.

I have been using wasm-tools component targets - but this requires strict versioning:

❯ wasm-tools component targets /path/to/wit /path/to/component --world 'my:package/my-world@1.0.0'
error: failed to validate encoded bytes

Caused by:
    0: type mismatch for import `my-world`
       missing import named `wasi:cli/environment@0.2.3` (at offset 0x6dba4)

Is there some other more appropriate way to do this validation?

Side-question, is the only thing that needs to be validated with wasi interfaces the minor version (0.2)?

Alex Crichton (May 30 2025 at 14:26):

Yes WASI interfaces only need to match the semver, I thought we had written this up in the component model repository but I fear I either am mis-remembering or I have misplaced those docs...

It's true that wasm-tools component targets doesn't yet support this semver-matching, although it'd be good to support it there!

Julien Vincent (May 30 2025 at 14:37):

@Alex Crichton Thanks for the confirmation. Any recommendations for how to proceed in the meantime?

Alex Crichton (May 30 2025 at 14:38):

one option is to update your world with include wasi:cli/imports@0.2.3; and include wasi:cli/imports@0.2.4;, but I realize that's probably not great. Otherwise I'm not sure if there's a great workaround, depends on your exact embedding/scenario. For example if you're using wasmtime you can create an InstancePre which validates that all the imports are available

Julien Vincent (Jun 03 2025 at 15:00):

@Alex Crichton From my understanding of the wit-bindgen tooling, I don't know how I would create a component which referenced that world containing all the wasi bingen code. Wouldn't I then need to provide implementations of those generated bindings?

For example:

wit_bindgen::generate!({
  world: "my:package/my-world-with-wasi-imports",
  generate_all,
  pub_export_macro: true,
  default_bindings_module: "sdk::bindings",
});

This produces all the wasi bindings that I would then need to provide an implementation for - but which are implemented in the rust target. Or maybe I am not understanding fully

Julien Vincent (Jun 03 2025 at 15:04):

Oh. You're saying in the wit files used to validate. But that would still fail validation AFAIU because the resulting wasm binary targets _either_ 0.2.4 or 0.2.3, not both

Julien Vincent (Jun 03 2025 at 15:05):

For example if you're using wasmtime you can create an InstancePre which validates that all the imports are available

In my case, the system validating the binary is a storage registry not written in rust. So this isn't really a viable option

Alex Crichton (Jun 04 2025 at 23:33):

Oh I was thinking that for targets you can have extra imports in the world you're testing against, e.g. both 0.2.{3,4}, and if you imported only one or the other then that's ok.

In general though this is probably something where we should improve the targets subcommand of wasm-tools

Last updated: Dec 06 2025 at 05:03 UTC