robherley added the bug label to Issue #10119.
robherley opened issue #10119:
Test Case
I have a minimal repro in this repository: https://github.com/robherley/wasmtime-bindgen-repro
Steps to Reproduce
Follow the example from wasmtime-wasi crate:
https://github.com/bytecodealliance/wasmtime/blob/58282df898d79a787a726d829b166272dde155b9/crates/wasi/src/bindings.rs#L39-L41Attempt to compile.
- Error, need to
cargo expand(see myexpanded.rs) or addinclude_generated_code_from_file: trueto the macro.Expected Results
The generated binding have the correction function signatures.
Actual Results
<img width="1040" alt="Image" src="https://github.com/user-attachments/assets/8b20dc15-a59b-491f-84a8-7b6c7a09d640" />
Versions and Environment
Wasmtime version or commit:
29.0.1Operating system:
macOS 15.1.1Architecture:
arm64Extra Info
The only affected bindings are:
__with_name0::cli::exit::add_to_linker(linker, get)?; __with_name0::sockets::network::add_to_linker(linker, get)?;Which are missing
&wasmtime_wasi::bindings::cli::exit::LinkOptionsand&wasmtime_wasi::bindings::sockets::network::LinkOptions
robherley commented on issue #10119:
I'm guessing this is related to runtime feature-gated options:
Instead, the generated add_to_linker*** functions take an additional LinkOptions parameter if the world/interface has any unstable features.
alexcrichton commented on issue #10119:
Thanks for the report! I think the problem may lie in your original WIT files perhaps? Looking at https://github.com/robherley/wasmtime-bindgen-repro/blob/main/wit/deps/wasi-cli-0.2.3/package.wit I don't see exit-with-code which is a feature-gated API, which means that the two bindgens are starting from different WITs?
robherley commented on issue #10119:
:wave: @alexcrichton Thanks for following up so fast! It does look like the wit does not match the bindings provided by
wasmtime_wasicrate.But, I resolved my
.witfiles from wkg:<img width="576" alt="Image" src="https://github.com/user-attachments/assets/e1f5f678-d577-4da3-81bb-49be3f91ada0" />
Which is odd, since the resolved version of
wasi-cli-0.2.3doesn't seem to haveexit-with-code?Even if I run:
wkg get wasi:cli@0.2.3 cat wasi_cli@0.2.3.wit | grep exit-with-codeThere is no reference to the
@unstable(feature = cli-exit-with-code).Is the version of
wasi:clion the registry incorrect? Or is there something else I'm misunderstanding
alexcrichton commented on issue #10119:
I think the issue might like with
wkgyeah, there's some subtelties around handling WIT and features which might need some patching. Mind opening an issue over there and cc'ing me?
robherley closed issue #10119:
Test Case
I have a minimal repro in this repository: https://github.com/robherley/wasmtime-bindgen-repro
Steps to Reproduce
Follow the example from wasmtime-wasi crate:
https://github.com/bytecodealliance/wasmtime/blob/58282df898d79a787a726d829b166272dde155b9/crates/wasi/src/bindings.rs#L39-L41Attempt to compile.
- Error, need to
cargo expand(see myexpanded.rs) or addinclude_generated_code_from_file: trueto the macro.Expected Results
The generated binding have the correction function signatures.
Actual Results
<img width="1040" alt="Image" src="https://github.com/user-attachments/assets/8b20dc15-a59b-491f-84a8-7b6c7a09d640" />
Versions and Environment
Wasmtime version or commit:
29.0.1Operating system:
macOS 15.1.1Architecture:
arm64Extra Info
The only affected bindings are:
__with_name0::cli::exit::add_to_linker(linker, get)?; __with_name0::sockets::network::add_to_linker(linker, get)?;Which are missing
&wasmtime_wasi::bindings::cli::exit::LinkOptionsand&wasmtime_wasi::bindings::sockets::network::LinkOptions
robherley commented on issue #10119:
Totally, I'll close this one out :+1:
Last updated: Dec 13 2025 at 21:03 UTC