wasm-tools/wit-component tinygo wasip2 component mismatch

[elewis787]

@jeff1010322 and I recently ran into an issue with the version of wasm-tools causing the following error:

handler.wasmexport_Handle#wasmexport\nnote: using the `WASMTIME_BACKTRACE_DETAILS=1` environment variable may show more debugging information",
    source: "unknown handle index 0",
}
error: hyper::Error(User(Service), guest never invoked `response-outparam::set` method: error while executing at wasm backtrace:
    0: 0x145611 - wit-component:shim!indirect-wasi:io/streams@0.2.0-[method]output-stream.blocking-write-and-flush
    1: 0xcbe5 - main!(internal/wasi/io/v0.2.0/streams.OutputStream).BlockingWriteAndFlush
    2: 0x1110c - main!runtime.putchar
    3: 0x11008 - main!runtime.printnl
    4: 0x10e93 - main!runtime.runtimePanicAt
    5: 0xc788 - main!runtime.runtimePanic
    6: 0xc93c - main!runtime.wasmExportCheckRun
    7: 0x417e6 - main!github.com/hayride-dev/bindings/go/wasihttp/gen/wasi/http/incoming-handler.wasmexport_Handle#wasmexport
note: using the `WASMTIME_BACKTRACE_DETAILS=1` environment variable may show more debugging information

Caused by:
    unknown handle index 0)

This occurred when using tinygo v0.34 and wit-component 0.215 when targeting wasip2.

In order to get this to work, wit-component needed to be set to at least 0.218 and used to embed wasip2 components.
This was uncovered by inspecting the wat generated off a tinygo compiled wasm component

i.e

    (@producers
    (language "C99" "")
    (processed-by "TinyGo" "0.35.0-dev")
    (processed-by "wit-component" "0.218.0")

There are envs for WASMTOOLS that can be set https://github.com/tinygo-org/tinygo/blob/release/builder/build.go#L885.

However, there seems to still be a potential for a mismatch tinygo wasip2 support and wasm-tools version support.

Would it be acceptable to submodule wasm-tools and default to using the built binary from tinygo, and optionally fall back to the env that is set for wasmtools?

Alternatively, when embedding a wit package/world, could we require a wasm-tools version that is supported and error on mismatch, something similar to the go/llvm required version?

[ydnar]

@Mossaka ran into this issue working on wasi-http-go.

Should we have TinyGo check the version of wasm-tools and warn if it is an older or unsupported version?

[elewis787]

I think that would be great. Happy to get a PR drafted - My main ask would be if you have an idea of where we can easily pin/map wasm-tool version to tinygo version.

[ydnar]

Should it be added to the Homebrew dependencies?

[elewis787]

Should it be added to the Homebrew dependencies?

That would make sense - we can start there.

[Mossaka]

My main ask would be if you have an idea of where we can easily pin/map wasm-tool version to tinygo version.

this is a difficult question to answer and I don't think anyone has an answer to it. Also wasm-tools has a pre-v1 version meaning that any new minor change could be a breaking change so you can't really always get the latest wasm-tools. My suggestion would be starting to document the versions we know are working, like TinyGo 0.34 and wit-component 0.218.0

[elewis787]

this is a difficult question to answer and I don't think anyone has an answer to it. Also wasm-tools has a pre-v1 version meaning that any new minor change could be a breaking change so you can't really always get the latest wasm-tools. My suggestion would be starting to document the versions we know are working, like TinyGo 0.34 and wit-component 0.218.0

I agree. I will look into finding any similar docs, in the meantime @jeff1010322 and I are thinking we could add something similar to the wasm-opt flows.

Do you think this would be a good first-step error if wasm-tools isn't found or a known minimum version isn't met?

We are also looking at adding a depends_on wasm-tools in https://github.com/tinygo-org/homebrew-tools