Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Support `wasm32v1-none`

Open
  • Is something wrong?
#4,629 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 2 days

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
rust, wasm
Domain
web-dev

Research direction

Start by auditing the winit-core, winit-web, and winit crates against the ten listed wasm32v1-none and no_std blockers, especially public APIs using PathBuf, Mutex, Instant, and io::Error. Build the relevant crates for wasm32v1-none first, then verify that the platform APIs and dependencies compile without the current std assumptions; done means the target builds with compatible web functionality.

Written by the indexing model from the issue text.

Description

S - enhancement
Description

When compiling for web, wasm32-unknown-unknown is currently the defacto target. However, this target has an evolving set of enabled Wasm features, which can cause browser compatibility issues. Rust's solution to this problem is the relatively recent wasm32v1-none target, which enables the bare minimum set of Wasm features, maintaining a consistent compatibility. Critically, this target also undoes the decision to use a stubbed std, opting instead for wasm32v1-none to just be a no_std target.

I noticed winit was missing this compatibility while working on wgpu#6826, as I have made enough progress to start working on examples.

Based on a cursory glance, here are some changes I think would need to be made:

  1. Warn on clippy::std_instead_of_core, clippy::std_instead_of_alloc, and clippy::alloc_instead_of_core and replace std usage with core and alloc where trivial.
  2. Add #![no_std] extern crate std; extern crate alloc; to winit-core, winit-web, and winit to swap from the std implicit prelude to the core implicit.
  3. Disable default features on most dependencies
  4. Add libm to winit-core. Note that dpi has an inlined subset of libm, I don't believe this is advisable for winit-core, as round, sin, cos, tan, atan, atan2, and hypot are all required.
  5. Change WindowEvent. The Drag events include public usage of PathBuf. Either the enum needs to be non_exhaustive with those arms gated, or some further encapsulation is required.
  6. SurfaceSizeWriter uses Mutex in its public API. This could be pretty easily abstracted with a new type wrapping either an alternate Mutex (e.g., spin), or it could just be a packed AtomicU64.
  7. web-time currently lacks no_std support for no particular reason, so either APIs involving Instant need to be gated, or further work upstream is required.
  8. BadIcon wraps an io::Error. This type is moved into core on nightly, but there's no ETA for stabilisation.
  9. winit-web makes extensive usage of thread_local's. These can be safely replaced with unsafe impl Send + Sync wrappers, since Wasm without atomics is trivially single threaded only. This is the approach wgpu uses.
  10. Probably need to bring in once_lock.
Relevant platforms

Web

Dominant language
Rust
Stars
6.2k
Forks
1.3k
Avg merge
2d 16h
Merged PRs (30d)
10

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from rust-windowing/winit

All issues in rust-windowing/winit

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.