-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Add test support for emscripten targets #610
Conversation
… definitions for emscripten
I'm waiting the build fails for wasm-unknown-emscripten so I can open a issue and link the error. |
This was changed when emscripten test support was added
This looks awesome, thanks! Would it be possible to avoid the large whitelist of functions in |
I think this will make libstd (and others crates) more difficult to maintain. Take for example the fork function, it is not available on emscripten (it is in the whitelist) but it is used in libstd. An user will only get an error if he tries to use a function that calls fork, but he can use all the others functions. This is the same approach used in emscripten, that also defines the prototype of some functions but does not provides an implementation. I don't know how many of the whitelisted functions are used in libstd, but I think removing them from libc would make it impossible to make libstd compile for emscripten. |
Oh ok in that case mind clarifying something? So does |
So, now I'm confused. It toke me some time to create the whitelist, and now I think I need to review it. fork and others functions can be removed and tests still pass, but the majority of the functions are still there. Some functions, for example Now I don't know what is the best approach here. If we remove these definitions, a library that uses them cannot be compiled, and must cfg_out functions that use these definitions. On the other hand, if we leave it, the library can be compiled but will fail to link (in case an unimplemented function is necessary, but I think it will link ok if no such a function is used). |
d30caf0
to
1ea20cb
Compare
|
The SDKs are built and stored on https://s3.amazonaws.com/mozilla-games/emscripten/. |
…ipten Conflicts: Cargo.lock src/unix/notbsd/linux/mips/mod.rs
Update the emscripten sdk, let's see how travis goes. I didn't work on the whitelist issue. |
The wasm build passed. |
Awesome, thanks @malbarbo! My only hesitation is the large whitelist of functions to ignore in |
☔ The latest upstream changes (presumably #649) made this pull request unmergeable. Please resolve the merge conflicts. |
@alexcrichton What needs to be done(finished-up) here to push this forward? |
@lilianmoraru I'd like to understand more about the whitelist of functions here that aren't tested, but other than that it should just be a rebase away from landing |
Note to self for follow-up(I've lost track of what needs to follow, I try to remember some of the points):
|
I might be terribly wrong, but isn't binaryen builds from the master? https://github.com/rust-lang/rust/blob/master/src/ci/docker/scripts/emscripten-wasm.sh#L31
at time of this writing, points on
It doesn't mean that you did something wrong. |
Thanks for taking this on @lilianmoraru! Other than the .travis.yml weirdness, was there anything I could help out with? |
@alexcrichton Nah. I pushed my changes to @malbarbo's branch( malbarbo#1 ), now I'll just wait. |
Rebase of rust-lang#610 and also move emscripten up much higher in the hierarchy to ensure that it doesn't have too much of a ripple effect on other platforms. This involved moving down a good number of definitions, but hopefully was done with care to not break anything!
Rebase of rust-lang#610 and also move emscripten up much higher in the hierarchy to ensure that it doesn't have too much of a ripple effect on other platforms. This involved moving down a good number of definitions, but hopefully was done with care to not break anything!
Add asmjs/wasm32 to CI Rebase of #610 and also move emscripten up much higher in the hierarchy to ensure that it doesn't have too much of a ripple effect on other platforms. This involved moving down a good number of definitions, but hopefully was done with care to not break anything!
I've rebased this in #742 with what I had in mind, basically just copying around a lot more things to avoid many changes to libc-test and ensure everything is validated on emscripten. |
Thanks again though for the patch @malbarbo! |
Rebase of rust-lang#610 and also move emscripten up much higher in the hierarchy to ensure that it doesn't have too much of a ripple effect on other platforms. This involved moving down a good number of definitions, but hopefully was done with care to not break anything!
Add asmjs/wasm32 to CI Rebase of #610 and also move emscripten up much higher in the hierarchy to ensure that it doesn't have too much of a ripple effect on other platforms. This involved moving down a good number of definitions, but hopefully was done with care to not break anything!
Personally, I would of liked to preserve the history of @malbarbo's work :( |
Egad sorry! I've merged it all into the other PR |
Add asmjs/wasm32 to CI Rebase of #610 and also move emscripten up much higher in the hierarchy to ensure that it doesn't have too much of a ripple effect on other platforms. This involved moving down a good number of definitions, but hopefully was done with care to not break anything!
Add asmjs/wasm32 to CI Rebase of #610 and also move emscripten up much higher in the hierarchy to ensure that it doesn't have too much of a ripple effect on other platforms. This involved moving down a good number of definitions, but hopefully was done with care to not break anything!
Add asmjs/wasm32 to CI Rebase of #610 and also move emscripten up much higher in the hierarchy to ensure that it doesn't have too much of a ripple effect on other platforms. This involved moving down a good number of definitions, but hopefully was done with care to not break anything!
Thanks @alexcrichton for finishing this! I was worried that removing the functions white list would be too disturbing. Moving emscripten up in the hierarchy was the right choice. @lilianmoraru sorry for not replaying to you messages..., I've been very busy lately. And thank you for helping moving this forward. |
Also fix some definitions to make the tests pass for asmjs-unknown-emscripten. The build fails for wasm-unknown-emscripten with an assert error.