Rust 1.15.1

Author: brson

_posts/2017-02-08-Rust-1.15.1.md

@@ -0,0 +1,112 @@
+---
+layout: post
+title: "Announcing Rust 1.15.1"
+author: The Rust Core Team
+---
+
+The Rust team is happy to announce the latest version of Rust, 1.15.1. Rust is a
+systems programming language focused on safety, speed, and concurrency.
+
+If you have a previous version of Rust installed, getting Rust 1.15.1 is as easy as:
+
+```bash
+$ rustup update stable
+```
+
+If you don't have it already, you can [download Rust][install] from the
+appropriate page on our website, and check out the [detailed release notes for
+1.15.1][notes] on GitHub.
+
+[install]: https://www.rust-lang.org/install.html
+[notes]: https://github.com/rust-lang/rust/blob/master/RELEASES.md#version-1151-2017-02-08
+
+### What's in 1.15.1 stable
+
+This release fixes a single issue, a soundness bug in the new
+`vec::IntoIter::as_mut_slice` method. The problem with this three line function
+was [discovered] just minutes after publishing Rust 1.15.0 (by Rust core team
+alum Huon Wilson no less - we need you now more than ever Huon!), and is a
+reminder that writing unsafe code is hard.
+
+[discovered]: https://www.reddit.com/r/rust/comments/5roiq7/announcing_rust_115/dd8vujs/
+
+`as_mut_slice` is a method on the `IntoIter` iterator for the `Vec` type that
+offers a mutable view into the buffer being iterated over. Conceptually it is
+simple: just return a reference to the buffer; and indeed the implementation is
+simple, but it's unsafe because `IntoIter` is implemented with an unsafe pointer
+to the buffer:
+
+```rust
+pub fn as_mut_slice(&self) -> &mut [T] {
+    unsafe {
+        slice::from_raw_parts_mut(self.ptr as *mut T, self.len())
+    }
+}
+```
+
+It's just about the simplest unsafe method one could ask for. Can you spot the
+error? Our reviewers didn't! This method takes a shared reference and unsafely
+derives from it a mutable reference. That is totally bogus because it means
+`as_mut_slice` can be used to produce multiple mutable references to the same
+buffer, which is the one single thing you must not do in Rust.
+
+Here's a simple example of what this bug would let you write, incorrectly:
+
+```rust
+fn main() {
+    let v = vec![0];
+    let v_iter = v.into_iter();
+    let slice1: &mut [_] = v_iter.as_mut_slice();
+    let slice2: &mut [_] = v_iter.as_mut_slice();
+    slice1[0] = 1;
+    slice2[0] = 2;
+}
+```
+
+Here both `slice1` and `slice2` are referencing the same mutable slice. Also
+notice that the iterator they are created from, `v_iter` is not declared
+mutable, which is a good indication something fishy is going on.
+
+The [solution] here is trivial, just change `&self` to `&mut self`:
+
+```rust
+pub fn as_mut_slice(&mut self) -> &mut [T] {
+    unsafe {
+        slice::from_raw_parts_mut(self.ptr as *mut T, self.len())
+    }
+}
+```
+
+[solution]: https://github.com/rust-lang/rust/pull/39466
+
+With that, proper uniqueness invariants are maintained, only one mutable slice
+can be created at a time, and `v_iter` must be declared mutable in order to pull
+out a mutable slice.
+
+So we made that change, and we're releasing a fix. In Rust we take pride in not
+breaking APIs, but since this is a new, minor feature, and the present
+implementation is spectacularly unsound, we decided to go ahead and release the
+fix immediately, hopefully before too many codebases pick it up - that is, we
+don't consider this a breaking change that requires a careful transition, but a
+necessary bug fix. For more about Rust's approach to ensuring stability see the
+["Stability as a Deliverable"][stab] blog post, [RFC 1122], on language
+evolution, and [RFC 1105], on library evolution (curiously, RFC 1105 does not
+actually contain any language allowing for library breakage due to soundness,
+but the intent has always been clear that Rust reserves the right to break code to
+fix soundness holes).
+
+[stab]: https://blog.rust-lang.org/2014/10/30/Stability.html
+[RFC 1122]: https://github.com/rust-lang/rfcs/blob/master/text/1122-language-semver.md
+[RFC 1105]: https://github.com/rust-lang/rfcs/blob/master/text/1105-api-evolution.md
+
+What can we learn from this? Well, it's at least good to be reminded why we
+endeavored to write a safe language in the first place: writing safe code is not
+easy. We have some ideas for how to catch this kind of problem earlier in the
+development process, but we haven't made any decisions yet.
+
+We apologize for the inconvenience. Let's go hack.
+
+### Contributors to 1.15.1
+
+We had 2 individuals contribute to Rust 1.15.1.
+[Thanks!](https://thanks.rust-lang.org/rust/1.15.1)