---

yaml
---
r: 195443
b: refs/heads/master
c: 464c18c
h: refs/heads/master
i:
  195441: b97dac1
  195439: 0a3c4e4
v: v3

Author: Manishearth

[refs]

@@ -1,5 +1,5 @@
 ---
-refs/heads/master: 4c1f5bd6dc03116c20938d11800c0da8f1a84615
+refs/heads/master: 464c18ce9cc6a29c2dcf83d3e78576dbc5390f3c
 refs/heads/snap-stage1: e33de59e47c5076a89eadeb38f4934f58a3618a6
 refs/heads/snap-stage3: b3317d68910900f135f9f38e43a7a699bc736b4a
 refs/heads/try: 961e0358e1a5c0faaef606e31e9965742c1643bf

trunk/src/doc/reference.md

@@ -1188,12 +1188,15 @@ the guarantee that these issues are never caused by safe code.
 
 * Data races
 * Dereferencing a null/dangling raw pointer
-* Mutating an immutable value/reference without `UnsafeCell`
 * Reads of [undef](http://llvm.org/docs/LangRef.html#undefined-values)
   (uninitialized) memory
 * Breaking the [pointer aliasing
   rules](http://llvm.org/docs/LangRef.html#pointer-aliasing-rules)
   with raw pointers (a subset of the rules used by C)
+* `&mut` and `&` follow LLVM’s scoped [noalias] model, except if the `&T`
+  contains an `UnsafeCell<U>`. Unsafe code must not violate these aliasing
+  guarantees.
+* Mutating an immutable value/reference without `UnsafeCell<U>`
 * Invoking undefined behavior via compiler intrinsics:
   * Indexing outside of the bounds of an object with `std::ptr::offset`
     (`offset` intrinsic), with
@@ -1210,6 +1213,8 @@ the guarantee that these issues are never caused by safe code.
   code. Rust's failure system is not compatible with exception handling in
   other languages. Unwinding must be caught and handled at FFI boundaries.
 
+[noalias]: http://llvm.org/docs/LangRef.html#noalias
+
 ##### Behaviour not considered unsafe
 
 This is a list of behaviour not considered *unsafe* in Rust terms, but that may

trunk/src/doc/trpl/method-syntax.md

@@ -50,9 +50,9 @@ parameter, of which there are three variants: `self`, `&self`, and `&mut self`.
 You can think of this first parameter as being the `x` in `x.foo()`. The three
 variants correspond to the three kinds of thing `x` could be: `self` if it's
 just a value on the stack, `&self` if it's a reference, and `&mut self` if it's
-a mutable reference. We should default to using `&self`, as it's the most
-common, as Rustaceans prefer borrowing over taking ownership, and references 
-over mutable references. Here's an example of all three variants:
+a mutable reference. We should default to using `&self`, as you should prefer
+borrowing over taking ownership, as well as taking immutable references
+over mutable ones. Here's an example of all three variants:
 
 ```rust
 struct Circle {

trunk/src/doc/trpl/ownership.md

@@ -472,10 +472,15 @@ thread-safe counterpart of `Rc<T>`.
 
 ## Lifetime Elision
 
-Earlier, we mentioned *lifetime elision*, a feature of Rust which allows you to
-not write lifetime annotations in certain circumstances. All references have a
-lifetime, and so if you elide a lifetime (like `&T` instead of `&'a T`), Rust
-will do three things to determine what those lifetimes should be.
+Rust supports powerful local type inference in function bodies, but it’s
+forbidden in item signatures to allow reasoning about the types just based in
+the item signature alone. However, for ergonomic reasons a very restricted
+secondary inference algorithm called “lifetime elision” applies in function
+signatures. It infers only based on the signature components themselves and not
+based on the body of the function, only infers lifetime paramters, and does
+this with only three easily memorizable and unambiguous rules. This makes
+lifetime elision a shorthand for writing an item signature, while not hiding
+away the actual types involved as full local inference would if applied to it.
 
 When talking about lifetime elision, we use the term *input lifetime* and
 *output lifetime*. An *input lifetime* is a lifetime associated with a parameter

trunk/src/doc/trpl/testing.md

@@ -231,7 +231,7 @@ pub fn add_two(a: i32) -> i32 {
 }
 
 #[cfg(test)]
-mod tests {
+mod test {
     use super::add_two;
 
     #[test]
@@ -241,7 +241,7 @@ mod tests {
 }
 ```
 
-There's a few changes here. The first is the introduction of a `mod tests` with
+There's a few changes here. The first is the introduction of a `mod test` with
 a `cfg` attribute. The module allows us to group all of our tests together, and
 to also define helper functions if needed, that don't become a part of the rest
 of our crate. The `cfg` attribute only compiles our test code if we're
@@ -260,7 +260,7 @@ pub fn add_two(a: i32) -> i32 {
 }
 
 #[cfg(test)]
-mod tests {
+mod test {
     use super::*;
 
     #[test]

trunk/src/libcore/error.rs

@@ -48,33 +48,30 @@
 //! For example,
 //!
 //! ```
-//! # #![feature(os, old_io, old_path)]
+//! #![feature(core)]
 //! use std::error::FromError;
-//! use std::old_io::{File, IoError};
-//! use std::os::{MemoryMap, MapError};
-//! use std::old_path::Path;
+//! use std::{io, str};
+//! use std::fs::File;
 //!
 //! enum MyError {
-//!     Io(IoError),
-//!     Map(MapError)
+//!     Io(io::Error),
+//!     Utf8(str::Utf8Error),
 //! }
 //!
-//! impl FromError<IoError> for MyError {
-//!     fn from_error(err: IoError) -> MyError {
-//!         MyError::Io(err)
-//!     }
+//! impl FromError<io::Error> for MyError {
+//!     fn from_error(err: io::Error) -> MyError { MyError::Io(err) }
 //! }
 //!
-//! impl FromError<MapError> for MyError {
-//!     fn from_error(err: MapError) -> MyError {
-//!         MyError::Map(err)
-//!     }
+//! impl FromError<str::Utf8Error> for MyError {
+//!     fn from_error(err: str::Utf8Error) -> MyError { MyError::Utf8(err) }
 //! }
 //!
 //! #[allow(unused_variables)]
 //! fn open_and_map() -> Result<(), MyError> {
-//!     let f = try!(File::open(&Path::new("foo.txt")));
-//!     let m = try!(MemoryMap::new(0, &[]));
+//!     let b = b"foo.txt";
+//!     let s = try!(str::from_utf8(b));
+//!     let f = try!(File::open(s));
+//!
 //!     // do something interesting here...
 //!     Ok(())
 //! }

trunk/src/libcore/option.rs

@@ -333,7 +333,7 @@ impl<T> Option<T> {
         }
     }
 
-    /// Moves the value `v` out of the `Option<T>` if the content of the `Option<T>` is a `Some(v)`.
+    /// Moves the value `v` out of the `Option<T>` if it is `Some(v)`.
     ///
     /// # Panics
     ///

trunk/src/librustc/middle/expr_use_visitor.rs

@@ -885,6 +885,11 @@ impl<'d,'t,'tcx,TYPER:mc::Typer<'tcx>> ExprUseVisitor<'d,'t,'tcx,TYPER> {
         }
     }
 
+    // When this returns true, it means that the expression *is* a
+    // method-call (i.e. via the operator-overload).  This true result
+    // also implies that walk_overloaded_operator already took care of
+    // recursively processing the input arguments, and thus the caller
+    // should not do so.
     fn walk_overloaded_operator(&mut self,
                                 expr: &ast::Expr,
                                 receiver: &ast::Expr,