bytecodealliance / cargo-component

A Cargo subcommand for creating WebAssembly components based on the component model proposal.
Apache License 2.0
462 stars 54 forks source link

Resource Static Methods Cause Build Failure When Imported #284

Open toadslop opened 5 months ago

toadslop commented 5 months ago

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
  4. cd ../importer
  5. 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](https://github.com/bytecodealliance/cargo-component/files/15184543/min-ex.zip)
FrankReh commented 5 months ago

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:exporter@0.1.0;

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:importer@0.1.0;

world my-world {
    import test:exporter/exports@0.1.0;
}

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 commented 5 months ago

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.

peterhuene commented 5 months ago

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

FrankReh commented 5 months ago

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

toadslop commented 5 months ago

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