https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.26.2 2018-04-02T07:06:19+00:00 2018-04-02T07:06:19+00:00 Mike Hommey mh@glandium.org 2018-04-02T07:05:30+00:00 urn:sha1:b647583c2df155f4741fa2b3e1fa6e4fb1f5868f 94d1970bba87f2d2893f6e934e4c3f02ed50604d moved the alloc::allocator module to core::heap, moving e.g. Alloc and Layout out of the alloc crate. While alloc::heap reexports them, it's better to use them from where they really come from. 2017-12-31T12:21:46+00:00 Ed Schouten ed@nuxi.nl 2017-12-31T12:21:46+00:00 urn:sha1:c661e385fd81afef808f414867cc44a6c897195e After #47089 lands, CloudABI will no longer be considered UNIX. We need to pick the right allocator flavour now. 2017-12-27T17:38:57+00:00 Ed Schouten ed@nuxi.nl 2017-12-27T17:38:57+00:00 urn:sha1:838fb4a6a0d11ac2c24189518415d181638af001 As CloudABI is a capability-based runtime environment, file descriptors are the mechanism that grants rights to a process. These file descriptors may be passed into processes on startup using a utility called cloudabi-run. Unlike the POSIX shell, cloudabi-run does not follow the UNIX model where file descriptors 0, 1 and 2 represent stdin, stdout and stderr. There can be arbitrary many (or few) file descriptors that can be provided. For this reason, CloudABI's C library also doesn't define STD*_FILENO. liblibc should also not declare these. Disable the code in liballoc_system that tries to print error messages over file descriptor 2. For now, let's keep this function quiet. We'll see if we can think of some other way to log this in the future. 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-20T14:56:53+00:00 Simon Sapin simon.sapin@exyr.org 2017-11-20T14:30:04+00:00 urn:sha1:21d899272a7fb39a497424e3260ddab773af7983 The GNU C library (glibc) is documented to always allocate with an alignment of at least 8 or 16 bytes, on 32-bit or 64-bit platforms: https://www.gnu.org/software/libc/manual/html_node/Aligned-Memory-Blocks.html This matches our use of `MIN_ALIGN` before this commit. However, even when libc is glibc, the program might be linked with another allocator that redefines the `malloc` symbol and friends. (The `alloc_jemalloc` crate does, in some cases.) So `alloc_system` doesn’t know which allocator it calls, and needs to be conservative in assumptions it makes. The C standard says: https://port70.net/%7Ensz/c/c11/n1570.html#7.22.3 > The pointer returned if the allocation succeeds is suitably aligned > so that it may be assigned to a pointer to any type of object > with a fundamental alignment requirement https://port70.net/~nsz/c/c11/n1570.html#6.2.8p2 > A fundamental alignment is represented by an alignment less than > or equal to the greatest alignment supported by the implementation > in all contexts, which is equal to `_Alignof (max_align_t)`. `_Alignof (max_align_t)` depends on the ABI and doesn’t seem to have a clear definition, but it seems to match our `MIN_ALIGN` in practice. However, the size of objects is rounded up to the next multiple of their alignment (since that size is also the stride used in arrays). Conversely, the alignment of a non-zero-size object is at most its size. So for example it seems ot be legal for `malloc(8)` to return a pointer that’s only 8-bytes-aligned, even if `_Alignof (max_align_t)` is 16. 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-10-12T05:46:02+00:00 Simon Sapin simon.sapin@exyr.org 2017-10-11T19:25:13+00:00 urn:sha1:818d2249475910fa1f7844486abb2d7239056d96 2017-09-10T17:59:42+00:00 Michal 'vorner' Vaner vorner@vorner.cz 2017-09-10T17:59:42+00:00 urn:sha1:94297c67465c3bd124063de717f7574491f5cc7d Annotate the allocator crates (allocator_system, allocator_jemalloc) by the type of allocator they are. If one is requested as an exe allocator, detect its type by the flags. This has the effect that using this (de jure wrong) configuration in the target spec works instead of producing a really unhelpful and arcane linker error: "exe-allocation-crate": "alloc_system" Fixes #43524. 2017-09-06T19:31:19+00:00 bgermann bgermann@users.noreply.github.com 2017-09-06T19:31:19+00:00 urn:sha1:5b76b8681c088d935b60da05e8ae81e2594f46f5 As pointed out in https://github.com/rust-lang/libc/commit/deb61c8, Solaris 10 does not support posix_memalign. Use memalign for all Solaris versions instead. With this change applied I am able to cross-build rustc for Solaris 10. 2017-08-25T20:18:21+00:00 Tamir Duberstein tamird@gmail.com 2017-08-19T23:54:17+00:00 urn:sha1:b3f50caee0e2f2f4d44e1c83bf73a112c2a398b1 Fixes #41701.