cargo-component icon indicating copy to clipboard operation
cargo-component copied to clipboard

Resource Static Methods Cause Build Failure When Imported

Open toadslop opened this issue 9 months ago • 5 comments

Hey all, I ran into an issue where I couldn't import static resource functions which were defined in another wasm component. I have a minimal example attached as a zip file below.

In the project, I have an cdylib called exporter that exports a single wit resource, called 'my-resource' with a single static method called 'get-static' which returns a string. I also have an project called importer that creates an executable that imports the resource with the static method. I find that when I build the importing package, I get the following error:

error: failed to validate component output

Caused by:
    export name `[static]my-resource.get-static` is not valid
    static resource name is not known in this context (at offset 0xb)

This issue doesn't happen when I change the static method to a normal method. Any idea what's going wrong here?

The steps to reproduce using the package below are as follows:

  1. unzip the folder.
  2. cd exporter
  3. cargo component build. You should see this output:
 Generating bindings for exporter (src\bindings.rs)
   Compiling wit-bindgen-rt v0.24.0
   Compiling exporter v0.1.0 (C:\Users\bnhei\source\min-ex\exporter)
    Finished dev [unoptimized + debuginfo] target(s) in 1.72s
    Creating component target\wasm32-wasi\debug\exporter.wasm
  1. cd ../importer
  2. cargo component build. You should see this output:
   Compiling wit-bindgen-rt v0.24.0
   Compiling importer v0.1.0 (C:\Users\bnhei\source\min-ex\importer)
    Finished dev [unoptimized + debuginfo] target(s) in 1.57s
    Creating component target\wasm32-wasi\debug\importer.wasm
error: failed to validate component output

Caused by:
    export name `[static]my-resource.get-static` is not valid
    static resource name is not known in this context (at offset 0xb)

min-ex.zip

toadslop avatar May 02 '24 06:05 toadslop

I was hoping to learn something by looking at this problem. For now, all I can do is confirm the cargo component build step from the binary importer directory fails, as stated above, confirm that the command wasm-tools validate <exporter wasm> succeeds, show the two wit files involved, and ask a question about the cargo-component test harness.

The exporter library's wit file:

exporter $ cat wit/test.wit 
package test:[email protected];

interface exports {
    resource my-resource {
        get-static: static func() -> string;
    }
}

world example {
    export exports;
}

The importer binary's wit file:

importer $ cat wit/test.wit 
package test:[email protected];

world my-world {
    import test:exporter/[email protected];
}

Can the cargo-component test harness be used to create and test this kind of scenario, where one build creates a Wasm component library, and another build would have to compose using it?

FrankReh avatar May 03 '24 11:05 FrankReh

I've gotten as far as seeing where the deepest code check is failing.

Here a field that is still empty is checked whether it contains the resource name. If I comment out this test, the component builds successfully.

https://github.com/bytecodealliance/wasm-tools/blob/df542a839b1fc6c1345c68abf5da21ca9ef5f9fe/crates/wasmparser/src/validator/component.rs#L3162-L3170

I don't know why the all_resource_names field is empty so maybe the test is wrong but maybe something should have gotten the "my-resource" name added.

FrankReh avatar May 03 '24 16:05 FrankReh

This should be fixed once cargo-component updates to a wit-component containing https://github.com/bytecodealliance/wasm-tools/pull/1530

peterhuene avatar May 03 '24 19:05 peterhuene

@toadslop Nice reproducer. Made it very easy to look into.

FrankReh avatar May 03 '24 22:05 FrankReh

You're welcome! Thanks for all the hard work on this great project!

toadslop avatar May 05 '24 23:05 toadslop