Skip to content

Run all crates.io tests against wasm target to uncover fresh bugs #38802

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
brson opened this issue Jan 3, 2017 · 5 comments
Closed

Run all crates.io tests against wasm target to uncover fresh bugs #38802

brson opened this issue Jan 3, 2017 · 5 comments
Assignees
Labels
C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC O-wasm Target: WASM (WebAssembly), http://webassembly.org/ T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue.

Comments

@brson
Copy link
Contributor

brson commented Jan 3, 2017

To quickly get an idea for the ecosystem support for wasm we can pretty quickly run all the tests in the world with cargobomb. I think it makes a lot of sense, once some of the other low-hanging fruit is fixed, to run all crates' test suites under wasm before making the final push for production.

@brson brson added the O-wasm Target: WASM (WebAssembly), http://webassembly.org/ label Jan 3, 2017
@Mark-Simulacrum Mark-Simulacrum added the C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC label Jul 26, 2017
@steveklabnik
Copy link
Member

Triage; this would be very cool! This isn't assigned to a team; I'm gonna ping @rust-lang/infra to see if they think this is feasible/worth spending resources on.

@kennytm kennytm added the T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue. label Dec 25, 2019
@Mark-Simulacrum
Copy link
Member

I think at this point we've stabilized WASM to the extent that this wouldn't really be helpful -- it's also true that many crates would panic or otherwise not work just because some features on WASM aren't implemented today. I could see us perhaps trying to test WASI with this, but I don't personally think keeping this open just for that is worth while. I'm going to assign @alexcrichton as the person with the most WASM knowledge on the infra team though, I think they probably can make the call whether something like this is worth it.

@steveklabnik
Copy link
Member

it's also true that many crates would panic or otherwise not work just because some features on WASM aren't implemented today.

Yeah, I mean, I think the original intention was to make sure that stuff worked properly, but I still think it would be cool to have some sort of "ecosystem report", like we could know how much of the ecosystem at least compiles on wasm, and let crate maintainers know if it doesn't, that kind of thing.

@rafaelcaricio
Copy link

We would need to filter out *-sys dependent crates and any crate that uses threads.

  1. Creates that use native extensions will need to adapt their build.rs to support WASI.
  2. Trying to run today crates that spawn threads will result in something like:
thread 'main' panicked at 'failed to spawn thread: Custom { kind: Other, error: "operation not supported on wasm yet" }', src/libcore/result.rs:1165:5

@Enselic
Copy link
Member

Enselic commented Sep 10, 2023

Triage: Closing since this was proposed for closing without objections, and WASM is since long "pushed for production".

@Enselic Enselic closed this as not planned Won't fix, can't repro, duplicate, stale Sep 10, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC O-wasm Target: WASM (WebAssembly), http://webassembly.org/ T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

7 participants