Working asmjs and wasm targets
This patch set results in a working standard library for the asmjs-unknown-emscripten and wasm32-unknown-emscripten targets. It is based on the work of @badboy and @rschulman.
It does a few things:
- Updates LLVM with the emscripten [fastcomp](https://github.com/rust-lang/llvm/pull/50) patches, which include the pnacl IR legalizer and the asm.js backend. This patch is thought not to have any significant effect on existing targets.
- Teaches rustbuild to correctly link C code with emscripten
- Updates gcc-rs to work correctly with emscripten
- Teaches rustbuild to run crate tests for emscripten with node
- Modifies Thread::new to return an error on emscripten, to facilitate debugging a common failure mode
- Modifies libtest to run in single-threaded mode for emscripten
- Ignores a host of tests that don't work yet, mostly dealing with threads and I/O
- Updates libc with wasm32 definitions (presently the same as asmjs)
- Adds a wasm32-unknown-emscripten target that feeds the output of LLVM's asmjs backend through emcc to generate wasm
Notes and caveats:
- This is only known to work with `--enable-rustbuild`.
- The wasm32 target can't be tested correctly yet because of issues in compiletest and limitations in node https://github.com/kripken/emscripten/issues/4542, but hello.rs does seem to work when run on node via the binaryen interpreter
- This requires an up to date installation of the emscripten sdk from its incoming branch
- Unwinding is very broken
- When enabling the emscripten targets jemalloc is disabled for all targets, which results in test failures for the host
Next steps are to fix the jemalloc issue, start building the two emscripten targets on the auto builders, then start producing nightlies.
https://github.com/rust-lang/rust/issues/36317 tracks work on this.
Fixes https://github.com/rust-lang/rust/issues/36515
Fixes https://github.com/rust-lang/rust/issues/36515
Fixes https://github.com/rust-lang/rust/issues/36356
rustc: More fixes for arch-independent hashing
In another attempt to fix#36793 this commit attempts to head off any future
problems by adding a custom `WidentUsizeHasher` which will widen any hashing of
`isize` and `usize` to a `u64` as necessary. This obviates the need for a
previous number of `as u64` annotations and will hopefully protect us against
future problems here.
Closes#36793 (hopefully)
In another attempt to fix#36793 this commit attempts to head off any future
problems by adding a custom `WidentUsizeHasher` which will widen any hashing of
`isize` and `usize` to a `u64` as necessary. This obviates the need for a
previous number of `as u64` annotations and will hopefully protect us against
future problems here.
Closes#36793 (hopefully)
This is a hack to support building targets that don't support jemalloc
alongside hosts that do. The jemalloc build is controlled by a feature
of the std crate, and if that feature changes between targets, it
invalidates the fingerprint of std's build script (this is a cargo
bug); so we must ensure that the feature set used by std is the same
across all targets, which means we have to build the alloc_jemalloc
crate for targets like emscripten, even if we don't use it.
Fix BufRead::read_until documentation.
Second paragraph already fully explains what happens when EOF is
encountered. The third paragraph (removed one) is spurious and
misleading.
Fixed wrong link in release notes
The link for the pull request updating hash_map to implement Debug was a copy of the previous link, this changes the link to the correct PR.
Suggesting a change to a comment that puzzled me
While reading this, the comment made it difficult for me to simply absorb the concept. It interrupted my reading flow, and I think this expresses the same meaning, but reads a bit better. It's trivial, but makes it easier for me to move on to the next line.
