Don't generate bindings with a synthetic package by alexcrichton · Pull Request #115 · bytecodealliance/wasi-rs

alexcrichton · 2025-09-05T23:34:07Z

This commit addresses an issue in Rust nightly with the Rust standard library. Notably what's happening is that the wasi crate is using a synthetic world/package called rust:wasi/bindings to generate bindings. This world includes wasi:cli/imports and wasi:http/imports. What's happening is that the Rust standard library is using one version of the wasi crate with one version of WASI bindings, but user crates might use something different. This fails to link because rust:wasi/bindings is asserted to be the same no matter what and there's two different wasi crate versions feeding into this which cause conflicts.

The fix in this commit is to skip using rust:wasi as a package and generate bindings directly from WASI packages themselves. These bindings correctly have versions in them and are versioned appropriately so there's no clash and merging proceeds as expected.

This required moving the bindings for wasi:http/imports into the generation of bindings for wasi:http/proxy, but that doesn't actually change the structure of the crate just how the generated bindings work out.

This commit addresses an issue in Rust nightly with the Rust standard library. Notably what's happening is that the `wasi` crate is using a synthetic world/package called `rust:wasi/bindings` to generate bindings. This world includes `wasi:cli/imports` and `wasi:http/imports`. What's happening is that the Rust standard library is using one version of the `wasi` crate with one version of WASI bindings, but user crates might use something different. This fails to link because `rust:wasi/bindings` is asserted to be the same no matter what and there's two different `wasi` crate versions feeding into this which cause conflicts. The fix in this commit is to skip using `rust:wasi` as a package and generate bindings directly from WASI packages themselves. These bindings correctly have versions in them and are versioned appropriately so there's no clash and merging proceeds as expected. This required moving the bindings for `wasi:http/imports` into the generation of bindings for `wasi:http/proxy`, but that doesn't actually change the structure of the crate just how the generated bindings work out.

alexcrichton · 2025-09-05T23:37:35Z

Courtesy of @pchickey this PR is solving this current breakage on nightly:

$ cat Cargo.toml
[package]
name = "wit-component-merge-repro"
version = "0.1.0"
edition = "2024"

[dependencies]
wasi = "=0.14.0"
$ cat src/main.rs
fn main() {
    let now = wasi::clocks::monotonic_clock::now();
    println!("Hello, world {now}!");
}
$ cargo +nightly-2025-09-04 build --target wasm32-wasip2
error: linking with `wasm-component-ld` failed: exit status: 1
  |
  = note:  "wasm-component-ld" "-flavor" "wasm" "--export" "__main_void" "--export" "cabi_realloc" "-z" "stack-size=1048576" "--stack-first" "--allow-undefined" "--no-demangle" "<sysroot>/lib/rustlib/wasm32-wasip2/lib/self-contained/crt1-command.o" "<2 object files omitted>" "<sysroot>/lib/rustlib/wasm32-wasip2/lib/libpanic_abort-*.rlib" "/Users/p.hickey/src/wit-component-merge-repro/target/wasm32-wasip2/debug/deps/{libwasi-45fb34f8a145884a,libwit_bindgen_rt-34790fea67077ff3,libbitflags-04c7d363c51124f5}.rlib" "<sysroot>/lib/rustlib/wasm32-wasip2/lib/{libstd-*,libwasi-*,libwasi-*,libwit_bindgen-*,libcfg_if-*,librustc_demangle-*,libstd_detect-*,libhashbrown-*,librustc_std_workspace_alloc-*,libminiz_oxide-*,libadler2-*,libunwind-*,liblibc-*}.rlib" "-l" "c" "<sysroot>/lib/rustlib/wasm32-wasip2/lib/{librustc_std_workspace_core-*,liballoc-*,libcore-*,libcompiler_builtins-*}.rlib" "-l" "wit_bindgen_cabi_realloc0_37_0" "-L" "/Users/p.hickey/src/wit-component-merge-repro/target/wasm32-wasip2/debug/build/wit-bindgen-rt-032c5c722475ea60/out" "-L" "<sysroot>/lib/rustlib/wasm32-wasip2/lib/self-contained" "-o" "/Users/p.hickey/src/wit-component-merge-repro/target/wasm32-wasip2/debug/deps/wit_component_merge_repro-3101829626d3e605.wasm" "--gc-sections" "-O0"
  = note: some arguments are omitted. use `--verbose` to show all linker arguments
  = note: error: failed to parse core wasm for componentization

          Caused by:
              0: updating metadata for section component-type:wit-bindgen:0.45.0:rust:wasi:bindings:encoded worldrust-wasi-from-crates-io-in-libstd
              1: failed to merge WIT package sets together
              2: failed to merge package `rust:wasi` into existing copy
              3: failed to merge world `bindings`
              4: import `wasi:io/poll@0.2.4` not found in target world


error: could not compile `wit-component-merge-repro` (bin "wit-component-merge-repro") due to 1 previous error

pchickey · 2025-09-05T23:45:51Z

src/proxy.rs

+    /// This type is primarily used in generated code for exported and imported
+    /// resources.
+    #[repr(transparent)]
+    pub struct Resource<T: WasmResource> {


I'm concerned we now have two different Resource structs defined - the wasi:http/types and outgoing-handler interfaces used to use the one now in imports, but now uses this one. They have identical text, but will we run into problems where the types arent actually equal?

Release a crate version with the fix from bytecodealliance#115

Release a crate version with the fix from #115

…tgross35 std: Update `wasi` crate dependency The recent work on the WASIp2 target being integrated into the standard library (rust-lang#146207, rust-lang#145944) ended up causing a bug in nightly on the target. This [has now been fixed](bytecodealliance/wasi-rs#115) in the `wasi` crate so this commit pulls in the updated version to ensure bindings work correctly.

Rollup merge of #146257 - alexcrichton:update-wasi-crate, r=tgross35 std: Update `wasi` crate dependency The recent work on the WASIp2 target being integrated into the standard library (#146207, #145944) ended up causing a bug in nightly on the target. This [has now been fixed](bytecodealliance/wasi-rs#115) in the `wasi` crate so this commit pulls in the updated version to ensure bindings work correctly.

…tgross35 std: Update `wasi` crate dependency The recent work on the WASIp2 target being integrated into the standard library (rust-lang#146207, rust-lang#145944) ended up causing a bug in nightly on the target. This [has now been fixed](bytecodealliance/wasi-rs#115) in the `wasi` crate so this commit pulls in the updated version to ensure bindings work correctly.

pchickey reviewed Sep 5, 2025

View reviewed changes

pchickey approved these changes Sep 5, 2025

View reviewed changes

alexcrichton merged commit 5e300f4 into bytecodealliance:main Sep 5, 2025
4 checks passed

alexcrichton deleted the fix-duplicate-wasi-crate-versions branch September 5, 2025 23:55

alexcrichton added a commit to alexcrichton/rust-wasi that referenced this pull request Sep 5, 2025

Bump to 0.14.4

9b39427

Release a crate version with the fix from bytecodealliance#115

alexcrichton mentioned this pull request Sep 5, 2025

Bump to 0.14.4 #116

Merged

alexcrichton added a commit that referenced this pull request Sep 5, 2025

Bump to 0.14.4 (#116)

b17d34b

Release a crate version with the fix from #115

alexcrichton mentioned this pull request Sep 6, 2025

std: Update wasi crate dependency rust-lang/rust#146257

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Don't generate bindings with a synthetic package#115

Don't generate bindings with a synthetic package#115
alexcrichton merged 1 commit intobytecodealliance:mainfrom
alexcrichton:fix-duplicate-wasi-crate-versions

alexcrichton commented Sep 5, 2025

Uh oh!

alexcrichton commented Sep 5, 2025

Uh oh!

pchickey Sep 5, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

alexcrichton commented Sep 5, 2025

Uh oh!

alexcrichton commented Sep 5, 2025

Uh oh!

pchickey Sep 5, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants