Is importname' rule has a typo?

[dannypsnl]

In the binary format

importname' ::= 0x00 len:<u32> in:<importname>                       => in  (if len = |in|)

however, when I dump the binary I got 0x01, is this a typo or version problem?

Tools version

• wasm-tools 1.216.0
• cargo-component-component 0.15.0

[alexcrichton]

Could you clarify what binary you're using and what you're seeing? Locally I see:

$ wasm-tools dump <<< "(component (import \"x\" (func)))"  
  0x0 | 00 61 73 6d | version 13 (Component)
      | 0d 00 01 00
  0x8 | 07 05       | component type section
  0xa | 01          | 1 count
  0xb | 40 00 01 00 | [type 0] Func(ComponentFuncType { params: [], results: Named([]) })
  0xf | 0a 06       | component import section
 0x11 | 01          | 1 count
 0x12 | 00 01 78 01 | [func 0] ComponentImport { name: ComponentImportName("x"), ty: Func(0) }
      | 00

where the import starts at 0x12. That has an 00 leading prefix, 01 78 is "x" and then 01 00 is "func index 0". Given all that it's expected that wasm-tools generates an 0x00 leading byte for imports.

[dannypsnl]

src/lib.rs

#[allow(warnings)]
mod bindings;

use bindings::Guest;

struct Component;

impl Guest for Component {
     fn add(x: i32, y: i32) -> i32 {
        x + y
    }
}

bindings::export!(Component with_types_in bindings);

wit/world.wit:

package component:add;

/// An example world for the component to target.
world example {
    export add: func(x: s32, y: s32) -> s32;
}

In Cargo.toml:

[dependencies]
wit-bindgen-rt = { version = "0.30.0", features = ["bitflags"] }

Use cargo component build get target/wasm32-wasip1/debug/add.wasm, in this file I got

     0x97 | 0a 18       | component import section
     0x99 | 01          | 1 count
     0x9a | 01 13 77 61 | [instance 2] ComponentImport { name: ComponentImportName("wasi:io/[email protected]"), ty: Instance(2) }
          | 73 69 3a 69
          | 6f 2f 65 72
          | 72 6f 72 40
          | 30 2e 32 2e
          | 30 05 02   

[alexcrichton]

Ah thanks for clarifying! You've discovered a situation where wasm-tools was in a "halfway state" in transitioning from one format to another. I've opened bytecodealliance/wasm-tools#1753 to fix this to always emit the 0x00 prefix byte. In that sense this bug is in wasm-tools, not the spec itself, and the spec as-written is correct.

[dannypsnl]

I see, thanks for clarifying.