---

yaml
---
r: 236091
b: refs/heads/stable
c: 7aee844
h: refs/heads/master
i:
  236089: c696a98
  236087: ab71ad9
v: v3

Author: Gankra

[refs]

@@ -29,7 +29,7 @@ refs/heads/tmp: afae2ff723393b3ab4ccffef6ac7c6d1809e2da0
 refs/tags/1.0.0-alpha.2: 4c705f6bc559886632d3871b04f58aab093bfa2f
 refs/tags/homu-tmp: f859507de8c410b648d934d8f5ec1c52daac971d
 refs/tags/1.0.0-beta: 8cbb92b53468ee2b0c2d3eeb8567005953d40828
-refs/heads/stable: 58f6f2d57a4d0a62f17003facd0d2406da75a035
+refs/heads/stable: 7aee8448ea461a598075065491e98f941a570fea
 refs/tags/1.0.0: 55bd4f8ff2b323f317ae89e254ce87162d52a375
 refs/tags/1.1.0: bc3c16f09287e5545c1d3f76b7abd54f2eca868b
 refs/tags/1.2.0: f557861f822c34f07270347b94b5280de20a597e

branches/stable/src/doc/tarpl/checked-uninit.md

@@ -4,7 +4,7 @@ Like C, all stack variables in Rust are uninitialized until a value is
 explicitly assigned to them. Unlike C, Rust statically prevents you from ever
 reading them until you do:
 
-```rust
+```rust,ignore
 fn main() {
     let x: i32;
     println!("{}", x);
@@ -39,7 +39,7 @@ fn main() {
 
 but this doesn't:
 
-```rust
+```rust,ignore
 fn main() {
     let x: i32;
     if true {

branches/stable/src/doc/tarpl/coercions.md

@@ -51,7 +51,7 @@ receivers, see below). If there is an impl for some type `U` and `T` coerces to
 following will not type check, even though it is OK to coerce `t` to `&T` and
 there is an impl for `&T`:
 
-```rust
+```rust,ignore
 trait Trait {}
 
 fn foo<X: Trait>(t: X) {}

branches/stable/src/doc/tarpl/destructors.md

@@ -3,7 +3,7 @@
 What the language *does* provide is full-blown automatic destructors through the
 `Drop` trait, which provides the following method:
 
-```rust
+```rust,ignore
 fn drop(&mut self);
 ```
 
@@ -23,13 +23,22 @@ this is totally fine.
 For instance, a custom implementation of `Box` might write `Drop` like this:
 
 ```rust
-struct Box<T>{ ptr: *mut T }
+#![feature(heap_api, core_intrinsics, unique)]
+
+use std::rt::heap;
+use std::ptr::Unique;
+use std::intrinsics::drop_in_place;
+use std::mem;
+
+struct Box<T>{ ptr: Unique<T> }
 
 impl<T> Drop for Box<T> {
     fn drop(&mut self) {
         unsafe {
-            (*self.ptr).drop();
-            heap::deallocate(self.ptr);
+            drop_in_place(*self.ptr);
+            heap::deallocate((*self.ptr) as *mut u8,
+                             mem::size_of::<T>(),
+                             mem::align_of::<T>());
         }
     }
 }
@@ -42,25 +51,36 @@ after-free the `ptr` because the Box is immediately marked as uninitialized.
 However this wouldn't work:
 
 ```rust
-struct Box<T>{ ptr: *mut T }
+#![feature(heap_api, core_intrinsics, unique)]
+
+use std::rt::heap;
+use std::ptr::Unique;
+use std::intrinsics::drop_in_place;
+use std::mem;
+
+struct Box<T>{ ptr: Unique<T> }
 
 impl<T> Drop for Box<T> {
     fn drop(&mut self) {
         unsafe {
-            (*self.ptr).drop();
-            heap::deallocate(self.ptr);
+            drop_in_place(*self.ptr);
+            heap::deallocate((*self.ptr) as *mut u8,
+                             mem::size_of::<T>(),
+                             mem::align_of::<T>());
         }
     }
 }
 
-struct SuperBox<T> { box: Box<T> }
+struct SuperBox<T> { my_box: Box<T> }
 
 impl<T> Drop for SuperBox<T> {
     fn drop(&mut self) {
         unsafe {
             // Hyper-optimized: deallocate the box's contents for it
             // without `drop`ing the contents
-            heap::deallocate(self.box.ptr);
+            heap::deallocate((*self.my_box.ptr) as *mut u8,
+                             mem::size_of::<T>(),
+                             mem::align_of::<T>());
         }
     }
 }
@@ -106,26 +126,39 @@ The classic safe solution to overriding recursive drop and allowing moving out
 of Self during `drop` is to use an Option:
 
 ```rust
-struct Box<T>{ ptr: *mut T }
+#![feature(heap_api, core_intrinsics, unique)]
+
+use std::rt::heap;
+use std::ptr::Unique;
+use std::intrinsics::drop_in_place;
+use std::mem;
+
+struct Box<T>{ ptr: Unique<T> }
 
 impl<T> Drop for Box<T> {
     fn drop(&mut self) {
         unsafe {
-            (*self.ptr).drop();
-            heap::deallocate(self.ptr);
+            drop_in_place(*self.ptr);
+            heap::deallocate((*self.ptr) as *mut u8,
+                             mem::size_of::<T>(),
+                             mem::align_of::<T>());
         }
     }
 }
 
-struct SuperBox<T> { box: Option<Box<T>> }
+struct SuperBox<T> { my_box: Option<Box<T>> }
 
 impl<T> Drop for SuperBox<T> {
     fn drop(&mut self) {
         unsafe {
             // Hyper-optimized: deallocate the box's contents for it
             // without `drop`ing the contents. Need to set the `box`
             // field as `None` to prevent Rust from trying to Drop it.
-            heap::deallocate(self.box.take().unwrap().ptr);
+            let my_box = self.my_box.take().unwrap();
+            heap::deallocate((*my_box.ptr) as *mut u8,
+                             mem::size_of::<T>(),
+                             mem::align_of::<T>());
+            mem::forget(my_box);
         }
     }
 }

branches/stable/src/doc/tarpl/drop-flags.md

@@ -31,6 +31,7 @@ And even branched code where all branches have the same behaviour with respect
 to initialization:
 
 ```rust
+# let condition = true;
 let mut x = Box::new(0);    // x was uninit; just overwrite.
 if condition {
     drop(x)                 // x gets moved out; make x uninit.
@@ -45,6 +46,7 @@ x = Box::new(0);            // x was uninit; just overwrite.
 However code like this *requires* runtime information to correctly Drop:
 
 ```rust
+# let condition = true;
 let x;
 if condition {
     x = Box::new(0);        // x was uninit; just overwrite.
@@ -56,6 +58,7 @@ if condition {
 Of course, in this case it's trivial to retrieve static drop semantics:
 
 ```rust
+# let condition = true;
 if condition {
     let x = Box::new(0);
     println!("{}", x);

branches/stable/src/doc/tarpl/exception-safety.md

@@ -156,7 +156,7 @@ way to do this is to store the algorithm's state in a separate struct with a
 destructor for the "finally" logic. Whether we panic or not, that destructor
 will run and clean up after us.
 
-```rust
+```rust,ignore
 struct Hole<'a, T: 'a> {
     data: &'a mut [T],
     /// `elt` is always `Some` from new until drop.

branches/stable/src/doc/tarpl/hrtb.md

@@ -28,7 +28,7 @@ fn main() {
 If we try to naively desugar this code in the same way that we did in the
 lifetimes section, we run into some trouble:
 
-```rust
+```rust,ignore
 struct Closure<F> {
     data: (u8, u16),
     func: F,
@@ -60,7 +60,7 @@ we enter the body of `call`! Also, that isn't some fixed lifetime; call works wi
 This job requires The Magic of Higher-Rank Trait Bounds. The way we desugar
 this is as follows:
 
-```rust
+```rust,ignore
 where for<'a> F: Fn(&'a (u8, u16)) -> &'a u8,
 ```
 
@@ -69,4 +69,4 @@ where for<'a> F: Fn(&'a (u8, u16)) -> &'a u8,
 `for<'a>` can be read as "for all choices of `'a`", and basically produces an
 *inifinite list* of trait bounds that F must satisfy. Intense. There aren't many
 places outside of the Fn traits where we encounter HRTBs, and even for those we
-have a nice magic sugar for the common cases.
+have a nice magic sugar for the common cases.

branches/stable/src/doc/tarpl/leaking.md

@@ -68,7 +68,7 @@ unwinding-safe! Easy!
 
 Now consider the following:
 
-```
+```rust,ignore
 let mut vec = vec![Box::new(0); 4];
 
 {
@@ -118,7 +118,7 @@ Nope.
 
 Let's consider a simplified implementation of Rc:
 
-```rust
+```rust,ignore
 struct Rc<T> {
     ptr: *mut RcBox<T>,
 }
@@ -183,7 +183,7 @@ in memory.
 The thread::scoped API intends to allow threads to be spawned that reference
 data on the stack without any synchronization over that data. Usage looked like:
 
-```rust
+```rust,ignore
 let mut data = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10];
 {
     let guards = vec![];
@@ -211,7 +211,7 @@ let mut data = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10];
 In principle, this totally works! Rust's ownership system perfectly ensures it!
 ...except it relies on a destructor being called to be safe.
 
-```
+```rust,ignore
 let mut data = Box::new(0);
 {
     let guard = thread::scoped(|| {

branches/stable/src/doc/tarpl/lifetime-elision.md

@@ -5,7 +5,7 @@ In order to make common patterns more ergonomic, Rust allows lifetimes to be
 
 A *lifetime position* is anywhere you can write a lifetime in a type:
 
-```rust
+```rust,ignore
 &'a T
 &'a mut T
 T<'a>
@@ -38,7 +38,7 @@ Elision rules are as follows:
 
 Examples:
 
-```rust
+```rust,ignore
 fn print(s: &str);                                      // elided
 fn print<'a>(s: &'a str);                               // expanded
 
@@ -61,4 +61,4 @@ fn args<'a, 'b, T:ToCStr>(&'a mut self, args: &'b [T]) -> &'a mut Command // exp
 fn new(buf: &mut [u8]) -> BufWriter;                    // elided
 fn new<'a>(buf: &'a mut [u8]) -> BufWriter<'a>          // expanded
 
-```
+```

branches/stable/src/doc/tarpl/lifetime-misc.md

@@ -10,8 +10,8 @@ types or lifetimes are logically associated with a struct, but not actually
 part of a field. This most commonly occurs with lifetimes. For instance, the `Iter`
 for `&'a [T]` is (approximately) defined as follows:
 
-```rust
-pub struct Iter<'a, T: 'a> {
+```rust,ignore
+struct Iter<'a, T: 'a> {
     ptr: *const T,
     end: *const T,
 }
@@ -33,7 +33,9 @@ Iter logically contains `&'a T`, so this is exactly what we tell
 the PhantomData to simulate:
 
 ```
-pub struct Iter<'a, T: 'a> {
+use std::marker;
+
+struct Iter<'a, T: 'a> {
     ptr: *const T,
     end: *const T,
     _marker: marker::PhantomData<&'a T>,
@@ -68,6 +70,8 @@ tell dropck that we *do* own values of type T, and may call destructors of that
 type, we must add extra PhantomData:
 
 ```
+use std::marker;
+
 struct Vec<T> {
     data: *const T, // *const for covariance!
     len: usize,
@@ -115,7 +119,7 @@ println!("{} {} {} {}", a, b, c, c2);
 However borrowck doesn't understand arrays or slices in any way, so this doesn't
 work:
 
-```rust
+```rust,ignore
 let x = [1, 2, 3];
 let a = &mut x[0];
 let b = &mut x[1];
@@ -144,7 +148,7 @@ left of the index, and one for everything to the right. Intuitively we know this
 is safe because the slices don't alias. However the implementation requires some
 unsafety:
 
-```rust
+```rust,ignore
 fn split_at_mut(&mut self, mid: usize) -> (&mut [T], &mut [T]) {
     unsafe {
         let self2: &mut [T] = mem::transmute_copy(&self);
@@ -189,8 +193,8 @@ Whether it's raw pointers, or safely composing on top of *another* IterMut.
 
 For instance, VecDeque's IterMut:
 
-```rust
-pub struct IterMut<'a, T:'a> {
+```rust,ignore
+struct IterMut<'a, T:'a> {
     // The whole backing array. Some of these indices are initialized!
     ring: &'a mut [T],
     tail: usize,

branches/stable/src/doc/tarpl/lifetimes.md

@@ -38,7 +38,7 @@ let z = &y;
 The borrow checker always tries to minimize the extent of a lifetime, so it will
 likely desugar to the following:
 
-```rust
+```rust,ignore
 // NOTE: `'a: {` and `&'b x` is not valid syntax!
 'a: {
     let x: i32 = 0;
@@ -69,8 +69,8 @@ z = y;
 The borrow checker always tries to minimize the extent of a lifetime, so it will
 likely desugar to something like the following:
 
-```rust
-// NOTE: `'a: {` and `&'b x` is not valid syntax!
+```rust,ignore
+// NOTE: `'a: {` and `foo = &'b x` is not valid syntax!
 'a: {
     let x: i32 = 0;
     'b: {
@@ -174,14 +174,14 @@ our implementation *just a bit*.)
 
 How about the other example:
 
-```rust
+```rust,ignore
 let mut data = vec![1, 2, 3];
 let x = &data[0];
 data.push(4);
 println!("{}", x);
 ```
 
-```rust
+```rust,ignore
 'a: {
     let mut data: Vec<i32> = vec![1, 2, 3];
     'b: {
@@ -219,4 +219,4 @@ semantics we're actually interested in preserving. For the most part, *that's
 totally ok*, because it keeps us from spending all day explaining our program
 to the compiler. However it does mean that several programs that are *totally*
 correct with respect to Rust's *true* semantics are rejected because lifetimes
-are too dumb.
+are too dumb.

branches/stable/src/doc/tarpl/ownership.md

@@ -16,7 +16,7 @@ issue...). This is a pervasive problem that C and C++ need to deal with.
 Consider this simple mistake that all of us who have used a non-GC'd language
 have made at one point:
 
-```rust
+```rust,ignore
 fn as_str(data: &u32) -> &str {
     // compute the string
     let s = format!("{}", data);
@@ -45,7 +45,7 @@ verifying that references don't escape the scope of their referent. That's
 because ensuring pointers are always valid is much more complicated than this.
 For instance in this code,
 
-```rust
+```rust,ignore
 let mut data = vec![1, 2, 3];
 // get an internal reference
 let x = &data[0];