https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.25.0 2018-01-17T17:57:13+00:00 2018-01-17T17:57:13+00:00 kennytm kennytm@gmail.com 2018-01-17T17:57:13+00:00 urn:sha1:175dd84ed8969fe136a4da1c7e5fe1d9c7693f2d Optimize slice.{r}position result bounds check Second attempt of https://github.com/rust-lang/rust/pull/45501 Fixes https://github.com/rust-lang/rust/issues/45964 Demo: https://godbolt.org/g/N4mBHp 2018-01-15T10:49:31+00:00 kennytm kennytm@gmail.com 2018-01-15T08:55:28+00:00 urn:sha1:5d0474ad73f2d9268f387726723fff44b88df3f7 Add slice::ExactChunks and ::ExactChunksMut iterators These guarantee that always the requested slice size will be returned and any leftoever elements at the end will be ignored. It allows llvm to get rid of bounds checks in the code using the iterator. This is inspired by the same iterators provided by ndarray. Fixes https://github.com/rust-lang/rust/issues/47115 I'll add unit tests for all this if the general idea and behaviour makes sense for everybody. Also see https://github.com/rust-lang/rust/issues/47115#issuecomment-354715511 for an example what this improves. 2018-01-13T10:19:01+00:00 Sebastian Dröge sebastian@centricular.com 2018-01-11T10:13:45+00:00 urn:sha1:5f4fc8214279f2ffadbf2cc3a4c22b748c17bd15 These are basically modified copies of the chunks/chunks_mut tests. 2018-01-13T10:19:00+00:00 Sebastian Dröge sebastian@centricular.com 2018-01-11T10:12:55+00:00 urn:sha1:ed774838b372bf532a3fb221601bdcd1c8856277 Easy enough to do and ensures that the whole chunk is as expected instead of just the element that was looked at before. 2018-01-12T21:58:25+00:00 arthurprs arthurprs@gmail.com 2018-01-10T19:39:11+00:00 urn:sha1:0b56ab0f7b0c5e01611b7ea6a28c77bc09c26275 2018-01-10T03:28:23+00:00 Corey Farwell coreyf@rwell.org 2018-01-10T03:28:23+00:00 urn:sha1:e2e8cd3d14f05c1362b11c2f7ae3561ce585bbc7 Deprecate [T]::rotate in favor of [T]::rotate_{left,right}. Background ========== Slices currently have an **unstable** [`rotate`] method which rotates elements in the slice to the _left_ N positions. [Here][tracking] is the tracking issue for this unstable feature. ```rust let mut a = ['a', 'b' ,'c', 'd', 'e', 'f']; a.rotate(2); assert_eq!(a, ['c', 'd', 'e', 'f', 'a', 'b']); ``` Proposal ======== Deprecate the [`rotate`] method and introduce `rotate_left` and `rotate_right` methods. ```rust let mut a = ['a', 'b' ,'c', 'd', 'e', 'f']; a.rotate_left(2); assert_eq!(a, ['c', 'd', 'e', 'f', 'a', 'b']); ``` ```rust let mut a = ['a', 'b' ,'c', 'd', 'e', 'f']; a.rotate_right(2); assert_eq!(a, ['e', 'f', 'a', 'b', 'c', 'd']); ``` Justification ============= I used this method today for my first time and (probably because I’m a naive westerner who reads LTR) was surprised when the docs mentioned that elements get rotated in a left-ward direction. I was in a situation where I needed to shift elements in a right-ward direction and had to context switch from the main problem I was working on and think how much to rotate left in order to accomplish the right-ward rotation I needed. Ruby’s `Array.rotate` shifts left-ward, Python’s `deque.rotate` shifts right-ward. Both of their implementations allow passing negative numbers to shift in the opposite direction respectively. The current `rotate` implementation takes an unsigned integer argument which doesn't allow the negative number behavior. Introducing `rotate_left` and `rotate_right` would: - remove ambiguity about direction (alleviating need to read docs 😉) - make it easier for people who need to rotate right [`rotate`]: https://doc.rust-lang.org/std/primitive.slice.html#method.rotate [tracking]: https://github.com/rust-lang/rust/issues/41891 2018-01-03T13:05:18+00:00 Sebastian Dröge sebastian@centricular.com 2018-01-03T10:25:18+00:00 urn:sha1:a56a3fc85f466c8488dccdfb78cfcd05740e0b36 For testing if the TrustedRandomAccess implementation works. 2017-12-25T07:01:24+00:00 Corey Farwell coreyf@rwell.org 2017-12-16T20:29:09+00:00 urn:sha1:66ef6b9c0995cc678a00f4d061ba8e6adb16f610 Background ========== Slices currently have an unstable [`rotate`] method which rotates elements in the slice to the _left_ N positions. [Here][tracking] is the tracking issue for this unstable feature. ```rust let mut a = ['a', 'b' ,'c', 'd', 'e', 'f']; a.rotate(2); assert_eq!(a, ['c', 'd', 'e', 'f', 'a', 'b']); ``` Proposal ======== Deprecate the [`rotate`] method and introduce `rotate_left` and `rotate_right` methods. ```rust let mut a = ['a', 'b' ,'c', 'd', 'e', 'f']; a.rotate_left(2); assert_eq!(a, ['c', 'd', 'e', 'f', 'a', 'b']); ``` ```rust let mut a = ['a', 'b' ,'c', 'd', 'e', 'f']; a.rotate_right(2); assert_eq!(a, ['e', 'f', 'a', 'b', 'c', 'd']); ``` Justification ============= I used this method today for my first time and (probably because I’m a naive westerner who reads LTR) was surprised when the docs mentioned that elements get rotated in a left-ward direction. I was in a situation where I needed to shift elements in a right-ward direction and had to context switch from the main problem I was working on and think how much to rotate left in order to accomplish the right-ward rotation I needed. Ruby’s `Array.rotate` shifts left-ward, Python’s `deque.rotate` shifts right-ward. Both of their implementations allow passing negative numbers to shift in the opposite direction respectively. Introducing `rotate_left` and `rotate_right` would: - remove ambiguity about direction (alleviating need to read docs 😉) - make it easier for people who need to rotate right [`rotate`]: https://doc.rust-lang.org/std/primitive.slice.html#method.rotate [tracking]: https://github.com/rust-lang/rust/issues/41891 2017-11-20T08:29:46+00:00 bors bors@rust-lang.org 2017-11-20T08:29:46+00:00 urn:sha1:41e03c3c469d1c89735fa518a9af4eb3df8b0728 std: Add a new wasm32-unknown-unknown target 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". ### Building yourself First you'll need to configure the build of LLVM and enable this target ``` $ ./configure --target=wasm32-unknown-unknown --set llvm.experimental-targets=WebAssembly ``` Next you'll want to remove any previously compiled LLVM as it needs to be rebuilt with WebAssembly support. You can do that with: ``` $ rm -rf build ``` And then you're good to go! A `./x.py build` should give you a rustc with the appropriate libstd target. ### Test support 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](https://reviews.llvm.org/D39866) to get that working and will take some time. Relatively simple programs all seem to work though! In general I've only tested this with a local fork that makes use of LLVM 5 rather than our current LLVM 4 on master. The LLVM 4 WebAssembly backend AFAIK isn't broken per se but is likely missing bug fixes available on LLVM 5. I'm hoping though that we can decouple the LLVM 5 upgrade and adding this wasm target! ### But the modules generated are huge! 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-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!