Rust 1.15.1

Author: brson

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

@@ -0,0 +1,114 @@
+---
+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. 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.
+
+What can we learn from this? Well, it's at least good to be reminded why we
+endeavoured to write a safe language in the first place, that writing
+memory-unsafe code is not easy. There have been some ideas suggested for process
+improvements that would catch this class of bug. Probably the simplest is just
+to ensure patches that touch unsafe blocks get more scrutiny during review: this
+patch was written by an expert Rust programmer, reviewed by an expert Rust
+programmer, but it appeared trivial and admittedly was not scrutinized closely.
+In this we could learn from our sister project, [Servo], which uses a bot to
+alert reviewers to pull requests that touch unsafe blocks. There are other ideas
+for validating unsafe blocks in Rust that are more thorough, from human-language
+attestation that the block is correct to bolt-on theorem provers. At the moment
+the Rust library team doesn't have plans to make process changes based on this
+mistake, but unsafe validation in Rust will be an area of active research
+forever, and we'll continue to evaluate our options.
+
+[Servo]: http://servo.org/
+
+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)