https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.26.2 2018-01-30T21:41:20+00:00 2018-01-30T21:41:20+00:00 Alex Crichton alex@alexcrichton.com 2018-01-30T19:54:07+00:00 urn:sha1:a2cc5d68a7d4a739b3da62540cb09f313de2f452 This commit adds a new option to target specifictions to specify that symbols should be "hidden" visibility by default in LLVM. While there are no existing targets that take advantage of this the `wasm32-unknown-unknown` target will soon start to use this visibility. The LLD linker currently interprets `hidden` as "don't export this from the wasm module" which is what we want for 90% of our functions. While the LLD linker does have a "export this symbol" argument which is what we use for other linkers, it was also somewhat easier to do this change instead which'll involve less arguments flying around. Additionally there's no need for non-`hidden` visibility for most of our symbols! This change should not immediately impact the wasm targets as-is, but rather this is laying the foundations for soon integrating LLD as a linker for wasm code. 2018-01-05T21:16:54+00:00 Ed Schouten ed@nuxi.nl 2018-01-05T21:16:54+00:00 urn:sha1:91611fc3d0ee8a7a0a7accff4377e3a21fd7b6c4 Ideally, we should make use of CloudABI's internal proc_raise(SIGABRT) system call. POSIX abort() requires things like flushing of stdios, which may not be what we want under panic conditions. Invoking the raw CloudABI system call would have prevented that. Unfortunately, we have to make use of the "cloudabi" crate to invoke raw CloudABI system calls. This is undesired, as discussed in the pull request (#47190). 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-08-25T20:18:21+00:00 Tamir Duberstein tamird@gmail.com 2017-08-19T23:54:17+00:00 urn:sha1:b3f50caee0e2f2f4d44e1c83bf73a112c2a398b1 Fixes #41701. 2017-01-08T08:22:06+00:00 bors bors@rust-lang.org 2017-01-08T08:22:06+00:00 urn:sha1:7ac9d337dcc544b4b1959997cdd36f1ba0c8d3e1 Remove not(stage0) from deny(warnings) Historically this was done to accommodate bugs in lints, but there hasn't been a bug in a lint since this feature was added which the warnings affected. Let's completely purge warnings from all our stages by denying warnings in all stages. This will also assist in tracking down `stage0` code to be removed whenever we're updating the bootstrap compiler. 2016-12-30T18:00:33+00:00 Alex Crichton alex@alexcrichton.com 2016-12-28T18:53:43+00:00 urn:sha1:a8535ce9d1045eebf92a477e846b720a08513cd0 Retain the same behavior as stable. Closes #38319 2016-12-30T05:07:20+00:00 Alex Crichton alex@alexcrichton.com 2016-12-29T17:47:34+00:00 urn:sha1:9b0b5b45dbd268aba0a79453f506bfe00bb57042 Historically this was done to accommodate bugs in lints, but there hasn't been a bug in a lint since this feature was added which the warnings affected. Let's completely purge warnings from all our stages by denying warnings in all stages. This will also assist in tracking down `stage0` code to be removed whenever we're updating the bootstrap compiler. 2016-12-12T21:55:09+00:00 Jeremy Soller jackpot51@gmail.com 2016-12-12T21:55:09+00:00 urn:sha1:7e7775ce7bfc916ce723bd1fdaf4ae54662c6627 2016-11-25T23:26:44+00:00 Ulrik Sverdrup bluss@users.noreply.github.com 2016-11-25T23:26:44+00:00 urn:sha1:17cb7bdd8340d9f83450ebd3e58b9f76e11cc01b 2016-11-11T03:37:34+00:00 Jeremy Soller jackpot51@gmail.com 2016-11-11T03:37:34+00:00 urn:sha1:0bb9a959074bb7f027cf05a240a0044116fa0ab0