typespec_client_core: New web_runtime to support wasm32-unknown-unknown

[magodo]

The typespec_client_core::sleep::sleep is using the async_runtime's sleep implementation, which is complicated to support wasm32, and will panic now when targeting to wasm32. Instead of make the standard_runtime to support wasm32 sleep (I wonder if it's feasible), we can instead just introduce another sleep implementation to simply use the gloo_timers::future::sleep.

Also, this PR adds a cfg_attr for conditionally remove the Send trait from the async_trait for the RetryPolicy, as the other parts of the code do.

Additionally, the getrandom crate will enable wasm_js features when targetting to wasm, which is necessary.

Fix #2754

[Copilot]

Pull Request Overview

This PR adds a WebAssembly-compatible sleep implementation using gloo_timers, adjusts async_trait attributes for WASM targets, and updates dependency declarations.

• Introduce a wasm-only sleep using gloo_timers::future::sleep
• Add cfg_attr macros to toggle async_trait for RetryPolicy on wasm32
• Update Cargo.toml files to include gloo-timers and necessary features

Reviewed Changes

Copilot reviewed 4 out of 5 changed files in this pull request and generated 2 comments.

File	Description
sdk/typespec/typespec_client_core/src/sleep.rs	Split sleep into non-WASM and WASM variants using cfgs
sdk/typespec/typespec_client_core/src/http/policies/retry/mod.rs	Apply cfg_attr to async_trait for WASM vs non-WASM targets
sdk/typespec/typespec_client_core/Cargo.toml	Add gloo-timers to WASM target dependencies
Cargo.toml	Declare gloo-timers with the futures feature at workspace root

Comments suppressed due to low confidence (1)

sdk/typespec/typespec_client_core/src/sleep.rs:36

• The WASM variant of sleep is missing a doc comment; consider adding one to explain its behavior and any conversion caveats.

pub async fn sleep(duration: Duration) {

[heaths]

Better, but a couple lingering changes.

[heaths]

Seems this line is no longer needed.

[magodo]

If we want to do #2770 (comment), this is still needed to allow a user to select the StdRuntime even target to wasm32.

[LarryOsterman]

Much better, but IMHO this should probably be tied to a specific feature which is the gloo runtime, unless you can assert safely that gloo is the runtime of choice for all wasm developers (I'm not familiar enough with wasm development to have an opinion here).

This is similar to how we've tied the tokio runtime to the tokio feature - because the tokio runtime is not a globally accepted async runtime, we hide its implementation behind a feature.

[magodo]

@LarryOsterman The gloo-timers is provided by https://github.com/rustwasm, which is built on top of wasm-bindgen and js-sys, providing a more user friendly API. So if we really want to introduce a feature, then I'd prpose to name it "wasm-bindgen(as thespawnis based onwasm-bindgen-futures, and the sleepis based ongloo-timers, which in turn based on wasm-bindgen`).

Whilst, I believe even we use the target for this create_async_runtime(), it only means we provide a default runtime for the users. They are still able to call set_async_runtime() to choose the runtime of their choice. Otherwise, if we do:

    #[cfg(feature = "wasm-bindgen")]
    {
        Arc::new(web_runtime::WasmBindgenRuntime) as Arc<dyn AsyncRuntime>
    }
    #[cfg(feature = "tokio")]
    {
        Arc::new(tokio_runtime::TokioRuntime) as Arc<dyn AsyncRuntime>
    }
    #[cfg(not(any(feature = "tokio", feature = "wasm-bindgen")))]
    {
        Arc::new(standard_runtime::StdRuntime)
    }

For users who target to wasm32-unknown-unknown, without specifying the wasm-bindgen feature, then they'll get a StdRuntime by default, which will only panic in any case.

[LarryOsterman]

I can totally get behind a wasm-bindgen feature name.

Thank you for your patience here :)

[magodo]

@LarryOsterman Sure, I've pushed a new commit to introduce that feature name, made the wasm dependencies optional, and only bring them by this new feature.

Going on holiday

[magodo]

Kindly ping @LarryOsterman