fix(timers): propagate unwind safety to user callbacks

[guybedford]

wasm-bindgen 0.2.117+ added MaybeUnwindSafe bounds on Closure::wrap and Closure::once, because closures handed to JS are invoked across a catch_unwind boundary under panic = "unwind". gloo-timers accepts arbitrary user FnOnce / FnMut callbacks, but its Closure::wrap(...) / Closure::once(...) calls fail to compile under panic=unwind because the Box::new(callback) as Box<dyn FnMut()> coercion (and the FnOnce trait selection) erase the static UnwindSafe bound that wasm-bindgen requires.

This breaks every downstream crate that pulls in gloo-timers and tests under -Cpanic=unwind — see the failure on MattiasBuelens/wasm-streams#35.

The fix:

• Surface the requirement at the public API. Timeout::new / Interval::new now require F: CallbackUnwindSafe, a marker that resolves to std::panic::UnwindSafe under panic = "unwind" on wasm and to a no-op blanket otherwise. Callers with non-UnwindSafe captures must wrap them in std::panic::AssertUnwindSafe at the call site, which is where the invariants can actually be reasoned about.

• Internally use Closure::wrap_assert_unwind_safe / Closure::once_assert_unwind_safe under panic=unwind to acknowledge the dyn-erasure explicitly. The public bound has already enforced the requirement at the call site, so the internal assertion is sound.

• Bump the minimum wasm-bindgen requirement to 0.2.117 (where the _assert_unwind_safe helpers were added).

// before
pub fn new<F>(millis: u32, callback: F) -> Timeout
where F: 'static + FnOnce(),
{
    let closure = Closure::once(callback);
    ...
}

// after
pub fn new<F>(millis: u32, callback: F) -> Timeout
where F: 'static + FnOnce() + CallbackUnwindSafe,
{
    #[cfg(all(target_arch = "wasm32", panic = "unwind"))]
    let closure = Closure::once_assert_unwind_safe(callback);
    #[cfg(not(all(target_arch = "wasm32", panic = "unwind")))]
    let closure = Closure::once(callback);
    ...
}

This is not a breaking change for existing users:

• Under panic = "abort" (the default), CallbackUnwindSafe is a blanket implemented for every T, so the bound is invisible. Every existing caller continues to compile unchanged.
• Under panic = "unwind", gloo-timers previously did not compile at all against wasm-bindgen 0.2.117+, so there are no existing panic=unwind callers to break. The change unblocks the configuration; it does not regress it.

Tested locally with cargo build -p gloo-timers --target wasm32-unknown-unknown (default panic strategy) and RUSTFLAGS="-Cpanic=unwind" cargo +nightly build -p gloo-timers --target wasm32-unknown-unknown -Zbuild-std=std,panic_unwind — both pass cleanly. A new panic_unwind_build CI job exercises the latter case so this regression cannot recur silently.

[Madoshakalaka]

The futures feature is broken now:

RUSTFLAGS='-Cpanic=unwind' cargo +nightly check -p gloo-timers --features futures --target wasm32-unknown-unknown -Zbuild-std=std,panic_unwind

fails with

  error[E0277]: the type `UnsafeCell<Option<Waker>>` may contain interior mutability and a reference
   may not be safely transferrable across a catch_unwind boundary
     --> crates/timers/src/future.rs:143:43
     ...
  note: required for `{closure@crates/timers/src/future.rs:143:43: 143:50}`
        to implement `CallbackUnwindSafe`

The CI job runs cargo build -p gloo-timers --target wasm32-unknown-unknown -Zbuild-std=std,panic_unwind with default features only so this went undetected.

[guybedford]

I added the fix for the futures case as well and a CI test to check that in future.

We have since landed the wasm-bindgen change that does these stricter assertions which will be going out in wasm-bindgen@0.2.122 - would be great to have this landed by then!