https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.24.0 2017-12-30T09:00:35+00:00 2017-12-30T09:00:35+00:00 Ed Schouten ed@nuxi.nl 2017-12-30T09:00:35+00:00 urn:sha1:df0a2e440e1c871aa8a7f38148ad74eed9b3539b The official jemalloc sources don't build cleanly on CloudABI yet, for the reason that some of its tracing frameworks try to access the global filesystem namespace, which CloudABI doesn't provide. Always make use of the malloc implementation used by the C library, which already happens to be jemalloc with some tiny build fixes. 2017-12-26T16:00:45+00:00 kennytm kennytm@gmail.com 2017-12-06T21:06:48+00:00 urn:sha1:2566fa25c7fefbd61e4251bda4407747a3023891 This reverts commit ab018c76e14b87f3c9e0b7384cc9b02d94779cd5. This also adds the `ToolBuild::is_ext_tool` field to replace the previous `ToolBuild::expectation` field, to indicate whether a build-failure of certain tool is essential. 2017-11-28T23:15:30+00:00 Tamir Duberstein tamird@gmail.com 2017-11-26T21:43:24+00:00 urn:sha1:94d02b896c3feb5e997b95a660e850c7ad8cbe74 The documentation states: "The name output should be the name of the library." and this is already done in more recently-added callers. 2017-11-20T15:22:17+00:00 Simon Sapin simon.sapin@exyr.org 2017-11-20T14:55:31+00:00 urn:sha1:43e32b53462e139c560672102724e8a8c859dbf7 Most often, this code is used through the `std::heap::Heap` and `#[gloabal_allocator]` indirection, so this branch is not optimized out anymore. 2017-11-20T15:22:17+00:00 Simon Sapin simon.sapin@exyr.org 2017-11-20T14:42:34+00:00 urn:sha1:2dd268b652cb42f4ebaa145c9e50cc6509c47d26 See previous commit’s message for what is expected of allocators in general, and https://github.com/jemalloc/jemalloc/issues/1072 for discussion of what jemalloc does specifically. 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