https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.23.0 2017-11-20T05:07:41+00:00 2017-11-20T05:07:41+00:00 Alex Crichton alex@alexcrichton.com 2017-10-23T03:01:00+00:00 urn:sha1:80ff0f74b0c4a8d384160af81a1b21f53622d8af This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a "custom linker" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed, rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error, but anything related to allocation works (aka `HashMap`, `Vec`, etc). * Naturally, any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The "linking" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target, so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's "production ready". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored, but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the "smallest possible wasm module" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final "bloat" in vanilla rustc (again, a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this, particularly on the various integration points if you've got better ideas of how to approach them! 2017-11-05T03:01:11+00:00 Alex Crichton alex@alexcrichton.com 2017-11-01T20:16:36+00:00 urn:sha1:fbf98697021173a30b84d9145df0966a23a2f9d2 Right now symbol exports, particularly in a cdylib, are handled by assuming that `pub extern` combined with `#[no_mangle]` means "export this". This isn't actually what we want for some symbols that the standard library uses to implement itself, for example symbols related to allocation. Additionally other special symbols like `rust_eh_personallity` have no need to be exported from cdylib crate types (only needed in dylib crate types). This commit updates how rustc handles these special symbols by adding to the hardcoded logic of symbols like `rust_eh_personallity` but also adding a new attribute, `#[rustc_std_internal_symbol]`, which forces the export level to be considered the same as all other Rust functions instead of looking like a C function. The eventual goal here is to prevent functions like `__rdl_alloc` from showing up as part of a Rust cdylib as it's just an internal implementation detail. This then further allows such symbols to get gc'd by the linker when creating a cdylib. 2017-11-04T04:28:13+00:00 bors bors@rust-lang.org 2017-11-04T04:28:13+00:00 urn:sha1:a4541525d5aa2cbf9c15e89cde513792e22a0318 [jemalloc] set correct excess in realloc_excess 2017-11-03T16:44:58+00:00 gnzlbg gonzalobg88@gmail.com 2017-11-03T16:44:58+00:00 urn:sha1:549ab77e2375f07f3c425eb4c95ba31547288176 2017-10-25T18:26:27+00:00 gnzlbg gonzalobg88@gmail.com 2017-10-25T18:22:08+00:00 urn:sha1:45ef01269936c6b0c02fc5c212a5cea632884b69 2017-10-25T12:46:02+00:00 gnzlbg gonzalobg88@gmail.com 2017-10-25T12:46:02+00:00 urn:sha1:f39594d4bb719b9af7fcb56b7e4cd5a8868a8c50 2017-10-25T12:29:22+00:00 gnzlbg gonzalobg88@gmail.com 2017-10-25T12:28:38+00:00 urn:sha1:e1a71e7b8a15026b1a8067135fccf3d18be0203d 2017-10-25T12:18:20+00:00 gnzlbg gonzalobg88@gmail.com 2017-10-25T08:22:24+00:00 urn:sha1:d16c140b7cd014f03064f6f66f35baaa0b9cb7ce 2017-10-15T19:10:07+00:00 Vadim Petrochenkov vadim.petrochenkov@gmail.com 2017-10-10T20:06:22+00:00 urn:sha1:9e0fc5ccd050201e77483b1efb2e6c76f47496f6 2017-10-12T00:35:53+00:00 Marco A L Barbosa malbarbo@gmail.com 2017-10-12T00:29:46+00:00 urn:sha1:03419c846af0dea71e38064223d5e51550350a61