Unknown placeholder import in `wasm32-unknown-unknown`

[dvn8weil]

Hi,
When i am trying to build my project containing the following uuid dependency :
uuid = {version = "1.16.0", features = ["v4", "js"]}
The .wat file contains these imports including the placeholder import that are creating issue in my usage of the wasm binary.

(import "__wbindgen_placeholder__" "__wbindgen_describe" (func $_ZN12wasm_bindgen19__wbindgen_describe17ha2b0f1d17785f195E (;2;) (type 0)))
  (import "__wbindgen_externref_xform__" "__wbindgen_externref_table_grow" (func $_ZN12wasm_bindgen9externref31__wbindgen_externref_table_grow17hdc9360a44cb6f2f5E (;3;) (type 1)))
  (import "__wbindgen_externref_xform__" "__wbindgen_externref_table_set_null" (func $_ZN12wasm_bindgen9externref35__wbindgen_externref_table_set_null17h2e60a48c28265f6eE (;4;)

Is there something that i am missing here?
Thanks!

[dvn8weil]

Steps to reproduce the issue :

1. Create a new rust project ,
2. Add the following to Cargo.toml

[dependencies]
uuid = {version = "1.16.0", features = ["v4", "js"]}
getrandom = {version = "0.2.2", features=["js"]}

[lib]
crate-type = ["cdylib"]

3. Add usage of uuid such as uuid::Uuid::new_v4()
4. compile with target as wasm32-unknown-unknown. Run cargo build --target wasm32-unknown-unknown --release.
5. wasm-tools print target/wasm32-unknown-unknown/release/<library_name>.wasm -o <library_name>.wat

[KodrAus]

Hi @dvn8weil 👋 I'm not entirely sure what the issue is here. It doesn't look especially uuid specific. uuid doesn't use getrandom by default anymore, do you still see the issue if you enable the rng-getrandom or rng-rand features of uuid? Keep in mind these are based on getrandom 0.3, and not 0.2.

Are you also building with the latest versions of rustc and wasm-bindgen?

[KodrAus]

Just coming back through some triage, I'm not quite sure what happened here, but if it's still an issue please feel free to re-open and we can try digging in deeper.

[dvn8weil]

Hi, apologies for the late reply :
I removed the get_random dependency.
Cargo.toml :

[package]
name = "uuid_test"
version = "0.1.0"
edition = "2024"

[dependencies]
uuid = {version = "1.17.0", features = ["v4", "js"]}

[lib]
crate-type = ["cdylib"]

but in the .wasm file , i get after cargo build --target wasm32-unknown-unknown --release , and converting it to .wat file by wasm-tools print target/wasm32-unknown-unknown/release/uuid_test.wasm -o uuid_test1.wat

there is still the placeholder import :
(import "__wbindgen_placeholder__" "__wbindgen_describe" (func $_ZN12wasm_bindgen19__wbindgen_describe17hd20bcaa9ef979b7fE (;2;) (type 3)))

[KodrAus]

@dvn8weil What platform are you trying to use your wasm in? And what’s the issue you’re running in to with those imports?

[dvn8weil]

@KodrAus Hi, I am just compiling the rust project with cargo build --target wasm32-unknown-unknown --release. Therein when i convert the .wasm file into .wat for better readability, it contains (the .wat file) such placeholder imports.
These imports shouldn't be present when using wasm32-unknonwn-unknown compatible dependencies.

I have updated my rustc with all its components, as well wasm-tools.

[KodrAus]

Hmm, do you know what the presence of these placeholders implies? Does it mean there’s a call somewhere to a function that isn’t being bindgen’d? It’s a bit tricky to tell exactly where the issue is here or how to fix it. uuid is already used in wasm environments pretty heavily so there must be some missing piece here.

[KodrAus]

I'm going to re-open this in case there's something we're doing/not doing here in uuid that's causing these imports to be added. I'm not sure yet whether these imports represent an issue with uuid, or an issue with the use-case. If they're always generated then does wasm-bindgen produce glue code that handles them?

[dvn8weil]

I think it should be then that these imports will be handled by the runtime environment/medium , such as browser or node.js.
So if uuid with the dependencies as this , is supported by those runtime environments, functions for these imports must be provided by those envs.

[KodrAus]

Ok, I've had a fresh look at this, and I believe the problem here is coming from the wasm RNG implementation used by getrandom, which we've also inlined into uuid through its js feature.

Those bindings require a table to work, probably because of their use of Uint8Array. In uuid, we might be able to work around this, since we never need to fill more than 16 bytes of random values. Since we inlined that code I'm not 100% sure what the failure modes it's protecting against are.

[KodrAus]

It doesn't look like removing the use of Uint8Array removes those references. You can get rid of them though by configuring uuid to use getrandom via the rng-getrandom feature, and configuring getrandom to use a custom backend, which you can then implement based on whatever your target has available.