---

yaml
---
r: 187135
b: refs/heads/try
c: ac6cab0
h: refs/heads/master
i:
  187133: 1f92f0c
  187131: 552869e
  187127: 0df8011
  187119: f9fffad
  187103: 4a0a8fc
  187071: cda4daa
  187007: dbf20b9
  186879: fb519b1
v: v3

Author: Keegan McAllister

[refs]

@@ -2,7 +2,7 @@
 refs/heads/master: b4c965ee803a4521d8b4575f634e036f93e408f3
 refs/heads/snap-stage1: e33de59e47c5076a89eadeb38f4934f58a3618a6
 refs/heads/snap-stage3: 3a96d6a9818fe2affc98a187fb1065120458cee9
-refs/heads/try: 160cf962e7efaca024202421e58a5c83f0d1cbe8
+refs/heads/try: ac6cab088791c497726ccdec24f6f97e709d5a62
 refs/tags/release-0.1: 1f5c5126e96c79d22cb7862f75304136e204f105
 refs/heads/dist-snap: ba4081a5a8573875fed17545846f6f6902c8ba8d
 refs/tags/release-0.2: c870d2dffb391e14efb05aa27898f1f6333a9596

branches/try/src/librustc_borrowck/borrowck/README.md

@@ -53,7 +53,7 @@ Here `x` represents some variable, `LV.f` is a field reference,
 and `*LV` is a pointer dereference. There is no auto-deref or other
 niceties. This means that if you have a type like:
 
-```text
+```rust
 struct S { f: uint }
 ```
 
@@ -82,13 +82,13 @@ SD = struct S<'LT...> { (f: TY)... }
 
 Now, imagine we had a program like this:
 
-```text
+```rust
 struct Foo { f: uint, g: uint }
 ...
 'a: {
-  let mut x: Box<Foo> = ...;
-  let y = &mut (*x).f;
-  x = ...;
+    let mut x: Box<Foo> = ...;
+    let y = &mut (*x).f;
+    x = ...;
 }
 ```
 
@@ -507,7 +507,7 @@ specify that the lifetime of the loan must be less than the lifetime
 of the `&Ty` pointer. In simple cases, this clause is redundant, since
 the `LIFETIME()` function will already enforce the required rule:
 
-```
+```rust
 fn foo(point: &'a Point) -> &'static f32 {
     &point.x // Error
 }
@@ -517,7 +517,7 @@ The above example fails to compile both because of clause (1) above
 but also by the basic `LIFETIME()` check. However, in more advanced
 examples involving multiple nested pointers, clause (1) is needed:
 
-```
+```rust
 fn foo(point: &'a &'b mut Point) -> &'b f32 {
     &point.x // Error
 }
@@ -536,7 +536,7 @@ which is only `'a`, not `'b`. Hence this example yields an error.
 As a final twist, consider the case of two nested *immutable*
 pointers, rather than a mutable pointer within an immutable one:
 
-```
+```rust
 fn foo(point: &'a &'b Point) -> &'b f32 {
     &point.x // OK
 }
@@ -558,7 +558,7 @@ The rules pertaining to `LIFETIME` exist to ensure that we don't
 create a borrowed pointer that outlives the memory it points at. So
 `LIFETIME` prevents a function like this:
 
-```
+```rust
 fn get_1<'a>() -> &'a int {
     let x = 1;
     &x
@@ -578,7 +578,7 @@ after we return and hence the remaining code in `'a` cannot possibly
 mutate it. This distinction is important for type checking functions
 like this one:
 
-```
+```rust
 fn inc_and_get<'a>(p: &'a mut Point) -> &'a int {
     p.x += 1;
     &p.x
@@ -631,7 +631,7 @@ maximum of `LT'`.
 
 Here is a concrete example of a bug this rule prevents:
 
-```
+```rust
 // Test region-reborrow-from-shorter-mut-ref.rs:
 fn copy_pointer<'a,'b,T>(x: &'a mut &'b mut T) -> &'b mut T {
     &mut **p // ERROR due to clause (1)
@@ -659,7 +659,7 @@ ways to violate the rules is to move the base pointer to a new name
 and access it via that new name, thus bypassing the restrictions on
 the old name. Here is an example:
 
-```
+```rust
 // src/test/compile-fail/borrowck-move-mut-base-ptr.rs
 fn foo(t0: &mut int) {
     let p: &int = &*t0; // Freezes `*t0`
@@ -679,7 +679,7 @@ danger is to mutably borrow the base path. This can lead to two bad
 scenarios. The most obvious is that the mutable borrow itself becomes
 another path to access the same data, as shown here:
 
-```
+```rust
 // src/test/compile-fail/borrowck-mut-borrow-of-mut-base-ptr.rs
 fn foo<'a>(mut t0: &'a mut int,
            mut t1: &'a mut int) {
@@ -700,7 +700,7 @@ of `t0`. Hence the claim `&mut t0` is illegal.
 Another danger with an `&mut` pointer is that we could swap the `t0`
 value away to create a new path:
 
-```
+```rust
 // src/test/compile-fail/borrowck-swap-mut-base-ptr.rs
 fn foo<'a>(mut t0: &'a mut int,
            mut t1: &'a mut int) {
@@ -718,7 +718,7 @@ careful to ensure this example is still illegal.
 referent is claimed, even freezing the base pointer can be dangerous,
 as shown in the following example:
 
-```
+```rust
 // src/test/compile-fail/borrowck-borrow-of-mut-base-ptr.rs
 fn foo<'a>(mut t0: &'a mut int,
            mut t1: &'a mut int) {
@@ -741,7 +741,7 @@ which is clearly unsound.
 However, it is not always unsafe to freeze the base pointer. In
 particular, if the referent is frozen, there is no harm in it:
 
-```
+```rust
 // src/test/run-pass/borrowck-borrow-of-mut-base-ptr-safe.rs
 fn foo<'a>(mut t0: &'a mut int,
            mut t1: &'a mut int) {
@@ -757,7 +757,7 @@ thing `t2` can be used for is to further freeze `*t0`, which is
 already frozen. In particular, we cannot assign to `*t0` through the
 new alias `t2`, as demonstrated in this test case:
 
-```
+```rust
 // src/test/run-pass/borrowck-borrow-mut-base-ptr-in-aliasable-loc.rs
 fn foo(t0: & &mut int) {
     let t1 = t0;
@@ -830,7 +830,7 @@ moves/uninitializations of the variable that is being used.
 
 Let's look at a simple example:
 
-```
+```rust
 fn foo(a: Box<int>) {
     let b: Box<int>;   // Gen bit 0.