Merge pull request #1942 from patiences/update-links

Update links

text/1211-mir.md

@@ -204,23 +204,22 @@ rest of the design:
 
 ### Prototype
 
-The MIR design being described here [has been prototyped][proto-crate]
-and can be viewed in the `nikomatsakis` repository on github. In
-particular, [the `repr` module][repr] defines the MIR representation,
-and [the `build` module][build] contains the code to create a MIR
+The MIR design being described can be found [here][crate]. In
+particular, [this module][mir] defines the MIR representation,
+and [this `build` module][build] contains the code to create a MIR
 representation from an AST-like form.
 
 For increased flexibility, as well as to make the code simpler, the
 prototype is not coded directly against the compiler's AST, but rather
-against an idealized representation defined by [the `HIR` trait][hir].
-Note that this HIR trait is entirely independent from the HIR discussed by
+against an idealized representation defined by [the `HAIR` trait][hair].
+Note that this HAIR trait is entirely independent from the HIR discussed by
 nrc in [RFC 1191][1191] -- you can think of it as an abstract trait
 that any high-level Rust IR could implement, including our current
 AST. Moreover, it's just an implementation detail and not part of the
 MIR being proposed here per se. Still, if you want to read the code,
 you have to understand its design.
 
-The `HIR` trait contains a number of opaque associated types for the
+The `HAIR` trait contains a number of opaque associated types for the
 various aspects of the compiler. For example, the type `H::Expr`
 represents an expression. In order to find out what kind of expression
 it is, the `mirror` method is called, which converts an `H::Expr` into
@@ -230,19 +229,19 @@ themselves, or else they may be additional `H::Expr` nodes. This
 allows the tree that is exported to differ in small ways from the
 actual tree within the compiler; the primary intention is to use this
 to model "adjustments" like autoderef. The code to convert from our
-current AST to the HIR is not yet complete, but it can be found in the
-[`tcx` module][tcx].
+current AST to the HAIR is not yet complete, but it can be found
+[here][hair-mod].
 
-Note that the HIR mirroring system is an experiment and not really
+Note that the HAIR mirroring system is an experiment and not really
 part of the MIR itself. It does however present an interesting option
 for (eventually) stabilizing access to the compiler's internals.
 
-[proto-crate]: https://github.com/nikomatsakis/rust/tree/mir/src/librustc_mir
-[repr]: https://github.com/nikomatsakis/rust/blob/mir/src/librustc_mir/repr.rs
-[build]: https://github.com/nikomatsakis/rust/tree/mir/src/librustc_mir/build
-[hir]: https://github.com/nikomatsakis/rust/blob/mir/src/librustc_mir/hir.rs
+[crate]: https://github.com/rust-lang/rust/tree/2532ad7d0b2edac1909ef0ef346230331200790b/src/librustc/mir
+[mir]: https://github.com/rust-lang/rust/blob/2532ad7d0b2edac1909ef0ef346230331200790b/src/librustc/mir/mod.rs
+[build]: https://github.com/rust-lang/rust/tree/fc04eaacc5bd5760e98cd3aa390dcc3ae795d12f/src/librustc_mir/build
+[hair]: https://github.com/rust-lang/rust/tree/fc04eaacc5bd5760e98cd3aa390dcc3ae795d12f/src/librustc_mir/hair
 [1191]: https://github.com/rust-lang/rfcs/pull/1191
-[tcx]: https://github.com/nikomatsakis/rust/blob/mir/src/librustc_mir/tcx/mod.rs
+[hair-mod]: https://github.com/rust-lang/rust/blob/21c61336bb9e327b90f4cb8e87a948be40eeafe5/src/librustc_mir/hair/mod.rs
 
 ### Overview of the MIR
 
@@ -660,6 +659,8 @@ more generalized protocol that [RFC 809][809] specifies works in
 more-or-less exactly the same way: when that is adopted uniformly, the
 need for shallow drop and the Box rvalue will go away.
 
+[809]: https://github.com/rust-lang/rfcs/blob/master/text/0809-box-and-in-for-stdlib.md
+
 ### Phasing
 
 Ideally, the translation to MIR would be done during type checking,
@@ -782,7 +783,7 @@ which desugars to a temporary and a constant reference:
 
     tmp0 = foo;
     tmp1 = 3
-    x = tmp(tmp1)
+    x = tmp0(tmp1)
 
 There is no particular *harm* in such constants: it would be very easy
 to optimize them away when reducing to LLVM bitcode, and if we do not