Why do we depend on wit-bindgen as a regular dependency

[briansmith]

My understanding is that wit-bindgen generates Rust code at build time. My understanding is that the generated code will basically never change in a substantial way because the ABIs for wasip2 and wasip3 pretty much mandate what is generated? Maybe this is less true for wasip3 than for wasip2 since wasip3 is less stable.

So, why not just generate that code and then check the generated code into getrandom, bypassing the wasip2 and wasip3 crates and all their dependencies?

I remember that we've avoided depending on windows-sys because it causes problems exactly analogous to the problems we're experiencing with wasip2 and wasip3 targets, and the solution for Windows is basically what I'm suggesting here.

[newpavlov]

In the past I tried to extract the relevant part for WASIp2, so we would not depend on the WASI crates similarly to WASIp1, but I haven't managed to do it easily. So I am open to PRs which would try to do it, but I do not plan to work on it myself.

[briansmith]

That's pretty much how I feel too! 🤣

[newpavlov]

cc @alexcrichton

[josephlr]

I think I'm in the exact same boat as everyone else on this thread. I think we want to do exactly this (check in the generated bindings just for random number generation). But I just don't know how to do it.

[alexcrichton]

I've created #828 as an example of what it would look like to check in generated bindings. Happy to help shepherd that along, or if that's too onerous I'm also happy to close that.

and all their dependencies

To clarify, the crates wasip2 and wasip3 depend on wit-bindgen and nothing else. The wit-bindgen crate has many optional dependencies for more features, none of which getrandom uses. Due to a bug in Cargo, however, all of these dependencies are showing up in downstream lock files. I mostly want to clarify that this does not affect build time, only lock files. (still significant, but I want to be clear on the impact)

[briansmith]

Due to a bug in Cargo, however, all of these dependencies are showing up in downstream lock files.

Which bug?

[briansmith]

I guess it can become something like this:

pub fn get_random_u64() -> u64 {
    #[cfg_attr(target_env="p2", wasm_import_module = "wasi:random/random@0.2.10")]
    #[cfg_attr(target_env="p3", wasm_import_module = "wasi:random/random@0.3.0-rc-2026-01-06")]
    unsafe extern "C" {
        #[link_name = "get-random-u64"]
        safe fn wit_import0() -> i64;
    }
    let ret = wit_import0();
    ret as u64
}


// This is a bit subtle, in addition to the `include!` above, but the general
// idea is that `wit-bindgen` generates a custom section of type information
// needed by `wasm-component-ld`. That needs to make its way to the linker and
// that's particularly tricky to do unfortunately. To force the linker to at
// least witness the object file with the custom section in it a `#[used]`
// static here refers to a function in the `p2`/`p3` modules which is adjacent
// to the custom section. This is then coupled with a lack of `#[inline]` below
// such that whenever this file itself is used it'll force the linker to look at
// this `#[used]` static, then look at the type section, and include that.
//
// Note that the linker will strip this static as well as the referred-to
// function as it's actually dead, but the linker will still preserve the type
// information since it's in a custom section, which is what we want.
#[used]
static _FORCE_SECTION_REF: fn() = _link_custom_section_describing_imports;

#[inline(never)]
pub fn _link_custom_section_describing_imports() {}

#[rustfmt::skip]
#[cfg(target_arch = "wasm32")]
#[cfg_attr(target_env = "p2", unsafe(
    link_section = "component-type:wit-bindgen:0.53.1:wasi:random@0.2.10:imports:encoded worldrust-rand-0.4.2"
)]
#[cfg_atrr(target_env = "p3", 
    unsafe(link_section = "component-type:wit-bindgen:0.53.1:wasi:random@0.3.0-rc-2026-01-06:imports:encoded worldrust-rand-0.4.2"
))]
#[doc(hidden)]
#[allow(clippy::octal_escapes)]
pub static __WIT_BINDGEN_COMPONENT_TYPE: [u8; 433] =  todo!();

[alexcrichton]

I believe the bug in question is rust-lang/cargo#10801.

I would not personally advocate for handwritten bindings myself because I believe auto-generation is more important, and I would additionally caution against handwriting in that it would increase maintainership burden because non-standard mechanisms would be needed to bind WASIp2/3 APIs. As a result WASIp2/3 maintainers (like myself) would be much less unable to help.