---

yaml
---
r: 163143
b: refs/heads/snap-stage3
c: 553ab27
h: refs/heads/master
i:
  163141: 18c2d5b
  163139: e6e6c66
  163135: 5253ebd
v: v3

Author: Arcterus

[refs]

@@ -1,7 +1,7 @@
 ---
 refs/heads/master: 9146a919b616e39e528e4d7100d16eef52f1f852
 refs/heads/snap-stage1: e33de59e47c5076a89eadeb38f4934f58a3618a6
-refs/heads/snap-stage3: ae60f9c59289adf8e46b2b3152f618caffc74bf4
+refs/heads/snap-stage3: 553ab271a31a9573fb6e95d03d8f4d00e17d6511
 refs/heads/try: 20cbbffeefc1f35e2ea63afce7b42fbd79611d42
 refs/tags/release-0.1: 1f5c5126e96c79d22cb7862f75304136e204f105
 refs/heads/dist-snap: ba4081a5a8573875fed17545846f6f6902c8ba8d

branches/snap-stage3/src/doc/guide-ownership.md

@@ -93,7 +93,7 @@ must have a deallocation for each allocation. Rust handles this for you. It
 knows that our handle, `x`, is the owning reference to our box. Rust knows that
 `x` will go out of scope at the end of the block, and so it inserts a call to
 deallocate the memory at the end of the scope. Because the compiler does this
-for us, it's impossible to forget. We always have exactly one deallocation paired
+for us, it's impossible to forget. We always exaclty one deallocations paired
 with each of our allocations.
 
 This is pretty straightforward, but what happens when we want to pass our box
@@ -186,11 +186,11 @@ This function takes ownership, because it takes a `Box`, which owns its
 contents. But then we give ownership right back.
 
 In the physical world, you can give one of your possessions to someone for a
-short period of time. You still own your possession, you're just letting someone
+short period of time. You still own your posession, you're just letting someone
 else use it for a while. We call that 'lending' something to someone, and that
 person is said to be 'borrowing' that something from you.
 
-Rust's ownership system also allows an owner to lend out a handle for a limited
+Rust's ownershp system also allows an owner to lend out a handle for a limited
 period. This is also called 'borrowing.' Here's a version of `add_one` which
 borrows its argument rather than taking ownership:
 
@@ -231,7 +231,7 @@ fn add_one(num: &int) -> int {
 
 Rust has a feature called 'lifetime elision,' which allows you to not write
 lifetime annotations in certain circumstances. This is one of them. Without
-eliding the lifetimes, `add_one` looks like this:
+eliding the liftimes, `add_one` looks like this:
 
 ```rust
 fn add_one<'a>(num: &'a int) -> int {
@@ -254,7 +254,7 @@ This part _declares_ our lifetimes. This says that `add_one` has one lifetime,
 fn add_two<'a, 'b>(...)
 ```
 
-Then in our parameter list, we use the lifetimes we've named:
+Then in our parameter list, we use the liftimes we've named:
 
 ```{rust,ignore}
 ...(num: &'a int) -> ...
@@ -279,7 +279,7 @@ fn main() {
 }
 ```
 
-As you can see, `struct`s can also have lifetimes. In a similar way to functions,
+As you can see, `struct`s can also have liftimes. In a similar way to functions,
 
 ```{rust}
 struct Foo<'a> {
@@ -295,7 +295,7 @@ x: &'a int,
 # }
 ```
 
-uses it. So why do we need a lifetime here? We need to ensure that any reference
+uses it. So why do we need a liftime here? We need to ensure that any reference
 to a `Foo` cannot outlive the reference to an `int` it contains.
 
 ## Thinking in scopes

branches/snap-stage3/src/doc/guide.md

@@ -3681,8 +3681,8 @@ Here's the second note, which lets us know where the first borrow would be over.
 This is useful, because if we wait to try to borrow `x` after this borrow is
 over, then everything will work.
 
-For more advanced patterns, please consult the [Ownership
-Guide](guide-ownership.html).  You'll also learn what this type signature with
+For more advanced patterns, please consult the [Lifetime
+Guide](guide-lifetimes.html).  You'll also learn what this type signature with
 the `'a` syntax is:
 
 ```{rust,ignore}

branches/snap-stage3/src/libcollections/btree/map.rs

@@ -1026,24 +1026,6 @@ impl<'a, K: Ord, V> OccupiedEntry<'a, K, V> {
 
 impl<K, V> BTreeMap<K, V> {
     /// Gets an iterator over the entries of the map.
-    ///
-    /// # Example
-    ///
-    /// ```
-    /// use std::collections::BTreeMap;
-    ///
-    /// let mut map = BTreeMap::new();
-    /// map.insert(1u, "a");
-    /// map.insert(2u, "b");
-    /// map.insert(3u, "c");
-    ///
-    /// for (key, value) in map.iter() {
-    ///     println!("{}: {}", key, value);
-    /// }
-    ///
-    /// let (first_key, first_value) = map.iter().next().unwrap();
-    /// assert_eq!((*first_key, *first_value), (1u, "a"));
-    /// ```
     #[unstable = "matches collection reform specification, waiting for dust to settle"]
     pub fn iter<'a>(&'a self) -> Entries<'a, K, V> {
         let len = self.len();

branches/snap-stage3/src/libcore/lib.rs

@@ -59,7 +59,7 @@
 #![allow(unknown_features, raw_pointer_deriving)]
 #![feature(globs, intrinsics, lang_items, macro_rules, phase)]
 #![feature(simd, unsafe_destructor, slicing_syntax)]
-#![feature(default_type_params, unboxed_closures)]
+#![feature(default_type_params)]
 #![deny(missing_docs)]
 
 mod macros;

branches/snap-stage3/src/librustc/lib.rs

@@ -88,7 +88,6 @@ pub mod middle {
     pub mod privacy;
     pub mod reachable;
     pub mod region;
-    pub mod recursion_limit;
     pub mod resolve;
     pub mod resolve_lifetime;
     pub mod stability;