diff --git a/README.md b/README.md
index a01758d48..2a59a40bb 100644
--- a/README.md
+++ b/README.md
@@ -37,5 +37,6 @@ be found.
 ```bash
 > cargo install mdbook-linkcheck
 ```
-You will need `mdbook` version `>= 0.1`. `linkcheck` will be run automatically
+
+You will need `mdbook` version `>= 0.2`. `linkcheck` will be run automatically
 when you run `mdbook build`.
diff --git a/book.toml b/book.toml
index ecbe513b7..b9092a969 100644
--- a/book.toml
+++ b/book.toml
@@ -5,6 +5,8 @@ description = "A guide to developing rustc"
 
 [output.html]
 
-[output.linkcheck]
-
 [output.html.search]
+
+[output.linkcheck]
+follow-web-links = true
+exclude = [ "crates\\.io", "gcc\\.godbolt\\.org" ]
diff --git a/ci/install.sh b/ci/install.sh
index 29e3a2f9b..80f8de4e8 100755
--- a/ci/install.sh
+++ b/ci/install.sh
@@ -20,5 +20,5 @@ function cargo_install() {
   fi
 }
 
-cargo_install mdbook 0.1.8
-cargo_install mdbook-linkcheck 0.1.2
+cargo_install mdbook 0.2
+cargo_install mdbook-linkcheck 0.2
diff --git a/src/appendix/background.md b/src/appendix/background.md
index efdce4f2a..dbfe6a3db 100644
--- a/src/appendix/background.md
+++ b/src/appendix/background.md
@@ -94,7 +94,7 @@ and Michael I. Schwartzbach is an incredible resource!
 Check out the subtyping chapter from the
 [Rust Nomicon](https://doc.rust-lang.org/nomicon/subtyping.html).
 
-See the [variance](./variance.html) chapter of this guide for more info on how
+See the [variance](../variance.html) chapter of this guide for more info on how
 the type checker handles variance.
 
 <a name="free-vs-bound"></a>
diff --git a/src/appendix/code-index.md b/src/appendix/code-index.md
index 75d35c6c5..e1bde6863 100644
--- a/src/appendix/code-index.md
+++ b/src/appendix/code-index.md
@@ -29,16 +29,16 @@ Item            |  Kind    | Short description           | Chapter            |
 `Ty<'tcx>` | struct | This is the internal representation of a type used for type checking | [Type checking] | [src/librustc/ty/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/type.Ty.html)
 `TyCtxt<'cx, 'tcx, 'tcx>` | type | The "typing context". This is the central data structure in the compiler. It is the context that you use to perform all manner of queries | [The `ty` modules] | [src/librustc/ty/context.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.TyCtxt.html)
 
-[The HIR]: hir.html
-[Identifiers in the HIR]: hir.html#hir-id
-[The parser]: the-parser.html
-[The Rustc Driver]: rustc-driver.html
-[Type checking]: type-checking.html
-[The `ty` modules]: ty.html
-[Rustdoc]: rustdoc.html
-[Emitting Diagnostics]: diag.html
-[Macro expansion]: macro-expansion.html
-[Name resolution]: name-resolution.html
-[Parameter Environment]: param_env.html
-[Trait Solving: Goals and Clauses]: traits/goals-and-clauses.html#domain-goals
-[Trait Solving: Lowering impls]: traits/lowering-rules.html#lowering-impls
+[The HIR]: ../hir.html
+[Identifiers in the HIR]: ../hir.html#hir-id
+[The parser]: ../the-parser.html
+[The Rustc Driver]: ../rustc-driver.html
+[Type checking]: ../type-checking.html
+[The `ty` modules]: ../ty.html
+[Rustdoc]: ../rustdoc.html
+[Emitting Diagnostics]: ../diag.html
+[Macro expansion]: ../macro-expansion.html
+[Name resolution]: ../name-resolution.html
+[Parameter Environment]: ../param_env.html
+[Trait Solving: Goals and Clauses]: ../traits/goals-and-clauses.html#domain-goals
+[Trait Solving: Lowering impls]: ../traits/lowering-rules.html#lowering-impls
diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md
index 44ac26ca3..5c7d82741 100644
--- a/src/appendix/glossary.md
+++ b/src/appendix/glossary.md
@@ -7,25 +7,25 @@ them better.
 Term                    | Meaning
 ------------------------|--------
 AST                     |  the abstract syntax tree produced by the syntax crate; reflects user syntax very closely.
-binder                  |  a "binder" is a place where a variable or type is declared; for example, the `<T>` is a binder for the generic type parameter `T` in `fn foo<T>(..)`, and \|`a`\|` ...` is a binder for the parameter `a`. See [the background chapter for more](./appendix/background.html#free-vs-bound)
-bound variable          |  a "bound variable" is one that is declared within an expression/term. For example, the variable `a` is bound within the closure expession \|`a`\|` a * 2`. See [the background chapter for more](./appendix/background.html#free-vs-bound)
+binder                  |  a "binder" is a place where a variable or type is declared; for example, the `<T>` is a binder for the generic type parameter `T` in `fn foo<T>(..)`, and \|`a`\|` ...` is a binder for the parameter `a`. See [the background chapter for more](./background.html#free-vs-bound)
+bound variable          |  a "bound variable" is one that is declared within an expression/term. For example, the variable `a` is bound within the closure expession \|`a`\|` a * 2`. See [the background chapter for more](./background.html#free-vs-bound)
 codegen                 |  the code to translate MIR into LLVM IR.
 codegen unit            |  when we produce LLVM IR, we group the Rust code into a number of codegen units. Each of these units is processed by LLVM independently from one another, enabling parallelism. They are also the unit of incremental re-use.
 completeness            |  completeness is a technical term in type theory. Completeness means that every type-safe program also type-checks. Having both soundness and completeness is very hard, and usually soundness is more important. (see "soundness").
-control-flow graph      |  a representation of the control-flow of a program; see [the background chapter for more](./appendix/background.html#cfg)
-CTFE                    |  Compile-Time Function Evaluation. This is the ability of the compiler to evaluate `const fn`s at compile time. This is part of the compiler's constant evaluation system. ([see more](./const-eval.html))
+control-flow graph      |  a representation of the control-flow of a program; see [the background chapter for more](./background.html#cfg)
+CTFE                    |  Compile-Time Function Evaluation. This is the ability of the compiler to evaluate `const fn`s at compile time. This is part of the compiler's constant evaluation system. ([see more](../const-eval.html))
 cx                      |  we tend to use "cx" as an abbreviation for context. See also `tcx`, `infcx`, etc.
-DAG                     |  a directed acyclic graph is used during compilation to keep track of dependencies between queries. ([see more](incremental-compilation.html))
-data-flow analysis      |  a static analysis that figures out what properties are true at each point in the control-flow of a program; see [the background chapter for more](./appendix/background.html#dataflow)
+DAG                     |  a directed acyclic graph is used during compilation to keep track of dependencies between queries. ([see more](../incremental-compilation.html))
+data-flow analysis      |  a static analysis that figures out what properties are true at each point in the control-flow of a program; see [the background chapter for more](./background.html#dataflow)
 DefId                   |  an index identifying a definition (see `librustc/hir/def_id.rs`). Uniquely identifies a `DefPath`.
 Double pointer          |  a pointer with additional metadata. See "fat pointer" for more.
 DST                     |  Dynamically-Sized Type. A type for which the compiler cannot statically know the size in memory (e.g. `str` or `[u8]`). Such types don't implement `Sized` and cannot be allocated on the stack. They can only occur as the last field in a struct. They can only be used behind a pointer (e.g. `&str` or `&[u8]`).
 empty type              |  see "uninhabited type".
 Fat pointer             |  a two word value carrying the address of some value, along with some further information necessary to put the value to use. Rust includes two kinds of "fat pointers": references to slices, and trait objects. A reference to a slice carries the starting address of the slice and its length. A trait object carries a value's address and a pointer to the trait's implementation appropriate to that value. "Fat pointers" are also known as "wide pointers", and "double pointers".
-free variable           |  a "free variable" is one that is not bound within an expression or term; see [the background chapter for more](./appendix/background.html#free-vs-bound)
-'gcx                    |  the lifetime of the global arena ([see more](ty.html))
+free variable           |  a "free variable" is one that is not bound within an expression or term; see [the background chapter for more](./background.html#free-vs-bound)
+'gcx                    |  the lifetime of the global arena ([see more](../ty.html))
 generics                |  the set of generic type parameters defined on a type or item
-HIR                     |  the High-level IR, created by lowering and desugaring the AST ([see more](hir.html))
+HIR                     |  the High-level IR, created by lowering and desugaring the AST ([see more](../hir.html))
 HirId                   |  identifies a particular node in the HIR by combining a def-id with an "intra-definition offset".
 HIR Map                 |  The HIR map, accessible via tcx.hir, allows you to quickly navigate the HIR and convert between various forms of identifiers.
 ICE                     |  internal compiler error. When the compiler crashes.
@@ -36,39 +36,39 @@ IR                      |  Intermediate Representation. A general term in compil
 local crate             |  the crate currently being compiled.
 LTO                     |  Link-Time Optimizations. A set of optimizations offered by LLVM that occur just before the final binary is linked. These include optimizations like removing functions that are never used in the final program, for example. _ThinLTO_ is a variant of LTO that aims to be a bit more scalable and efficient, but possibly sacrifices some optimizations. You may also read issues in the Rust repo about "FatLTO", which is the loving nickname given to non-Thin LTO. LLVM documentation: [here][lto] and [here][thinlto]
 [LLVM]                  |  (actually not an acronym :P) an open-source compiler backend. It accepts LLVM IR and outputs native binaries. Various languages (e.g. Rust) can then implement a compiler front-end that output LLVM IR and use LLVM to compile to all the platforms LLVM supports.
-MIR                     |  the Mid-level IR that is created after type-checking for use by borrowck and codegen ([see more](./mir/index.html))
-miri                    |  an interpreter for MIR used for constant evaluation ([see more](./miri.html))
-normalize               |  a general term for converting to a more canonical form, but in the case of rustc typically refers to [associated type normalization](./traits/associated-types.html#normalize)
+MIR                     |  the Mid-level IR that is created after type-checking for use by borrowck and codegen ([see more](../mir/index.html))
+miri                    |  an interpreter for MIR used for constant evaluation ([see more](../miri.html))
+normalize               |  a general term for converting to a more canonical form, but in the case of rustc typically refers to [associated type normalization](../traits/associated-types.html#normalize)
 newtype                 |  a "newtype" is a wrapper around some other type (e.g., `struct Foo(T)` is a "newtype" for `T`). This is commonly used in Rust to give a stronger type for indices.
-NLL                     | [non-lexical lifetimes](./borrow_check/region_inference.html), an extension to Rust's borrowing system to make it be based on the control-flow graph.
+NLL                     | [non-lexical lifetimes](../borrow_check/region_inference.html), an extension to Rust's borrowing system to make it be based on the control-flow graph.
 node-id or NodeId       |  an index identifying a particular node in the AST or HIR; gradually being phased out and replaced with `HirId`.
-obligation              |  something that must be proven by the trait system ([see more](traits/resolution.html))
-projection              |  a general term for a "relative path", e.g. `x.f` is a "field projection", and `T::Item` is an ["associated type projection"](./traits/goals-and-clauses.html#trait-ref)
-promoted constants      |  constants extracted from a function and lifted to static scope; see [this section](./mir/index.html#promoted) for more details.
-provider                |  the function that executes a query ([see more](query.html))
-quantified              |  in math or logic, existential and universal quantification are used to ask questions like "is there any type T for which is true?" or "is this true for all types T?"; see [the background chapter for more](./appendix/background.html#quantified)
-query                   |  perhaps some sub-computation during compilation ([see more](query.html))
+obligation              |  something that must be proven by the trait system ([see more](../traits/resolution.html))
+projection              |  a general term for a "relative path", e.g. `x.f` is a "field projection", and `T::Item` is an ["associated type projection"](../traits/goals-and-clauses.html#trait-ref)
+promoted constants      |  constants extracted from a function and lifted to static scope; see [this section](../mir/index.html#promoted) for more details.
+provider                |  the function that executes a query ([see more](../query.html))
+quantified              |  in math or logic, existential and universal quantification are used to ask questions like "is there any type T for which is true?" or "is this true for all types T?"; see [the background chapter for more](./background.html#quantified)
+query                   |  perhaps some sub-computation during compilation ([see more](../query.html))
 region                  |  another term for "lifetime" often used in the literature and in the borrow checker.
-rib                     |  a data structure in the name resolver that keeps track of a single scope for names. ([see more](./name-resolution.html))
+rib                     |  a data structure in the name resolver that keeps track of a single scope for names. ([see more](../name-resolution.html))
 sess                    |  the compiler session, which stores global data used throughout compilation
 side tables             |  because the AST and HIR are immutable once created, we often carry extra information about them in the form of hashtables, indexed by the id of a particular node.
 sigil                   |  like a keyword but composed entirely of non-alphanumeric tokens. For example, `&` is a sigil for references.
-skolemization           |  a way of handling subtyping around "for-all" types (e.g., `for<'a> fn(&'a u32)`) as well as solving higher-ranked trait bounds (e.g., `for<'a> T: Trait<'a>`). See [the chapter on skolemization and universes](./borrow_check/region_inference.html#skol) for more details.
+skolemization           |  a way of handling subtyping around "for-all" types (e.g., `for<'a> fn(&'a u32)`) as well as solving higher-ranked trait bounds (e.g., `for<'a> T: Trait<'a>`). See [the chapter on skolemization and universes](../borrow_check/region_inference.html#skol) for more details.
 soundness               |  soundness is a technical term in type theory. Roughly, if a type system is sound, then if a program type-checks, it is type-safe; i.e. I can never (in safe rust) force a value into a variable of the wrong type. (see "completeness").
 span                    |  a location in the user's source code, used for error reporting primarily. These are like a file-name/line-number/column tuple on steroids: they carry a start/end point, and also track macro expansions and compiler desugaring. All while being packed into a few bytes (really, it's an index into a table). See the Span datatype for more.
 substs                  |  the substitutions for a given generic type or item (e.g. the `i32`, `u32` in `HashMap<i32, u32>`)
-tcx                     |  the "typing context", main data structure of the compiler ([see more](ty.html))
-'tcx                    |  the lifetime of the currently active inference context ([see more](ty.html))
-trait reference         |  the name of a trait along with a suitable set of input type/lifetimes ([see more](./traits/goals-and-clauses.html#trait-ref))
-token                   |  the smallest unit of parsing. Tokens are produced after lexing ([see more](the-parser.html)).
+tcx                     |  the "typing context", main data structure of the compiler ([see more](../ty.html))
+'tcx                    |  the lifetime of the currently active inference context ([see more](../ty.html))
+trait reference         |  the name of a trait along with a suitable set of input type/lifetimes ([see more](../traits/goals-and-clauses.html#trait-ref))
+token                   |  the smallest unit of parsing. Tokens are produced after lexing ([see more](../the-parser.html)).
 [TLS]                   |  Thread-Local Storage. Variables may be defined so that each thread has its own copy (rather than all threads sharing the variable). This has some interactions with LLVM. Not all platforms support TLS.
 trans                   |  the code to translate MIR into LLVM IR. Renamed to codegen.
-trait reference         |  a trait and values for its type parameters ([see more](ty.html)).
-ty                      |  the internal representation of a type ([see more](ty.html)).
-UFCS                    |  Universal Function Call Syntax. An unambiguous syntax for calling a method ([see more](type-checking.html)).
+trait reference         |  a trait and values for its type parameters ([see more](../ty.html)).
+ty                      |  the internal representation of a type ([see more](../ty.html)).
+UFCS                    |  Universal Function Call Syntax. An unambiguous syntax for calling a method ([see more](../type-checking.html)).
 uninhabited type        |  a type which has _no_ values. This is not the same as a ZST, which has exactly 1 value. An example of an uninhabited type is `enum Foo {}`, which has no variants, and so, can never be created. The compiler can treat code that deals with uninhabited types as dead code, since there is no such value to be manipulated. `!` (the never type) is an uninhabited type. Uninhabited types are also called "empty types".
 upvar                   |  a variable captured by a closure from outside the closure.
-variance                |  variance determines how changes to a generic type/lifetime parameter affect subtyping; for example, if `T` is a subtype of `U`, then `Vec<T>` is a subtype `Vec<U>` because `Vec` is *covariant* in its generic parameter. See [the background chapter](./appendix/background.html#variance) for a more general explanation. See the [variance chapter](./variance.html) for an explanation of how type checking handles variance.
+variance                |  variance determines how changes to a generic type/lifetime parameter affect subtyping; for example, if `T` is a subtype of `U`, then `Vec<T>` is a subtype `Vec<U>` because `Vec` is *covariant* in its generic parameter. See [the background chapter](./background.html#variance) for a more general explanation. See the [variance chapter](../variance.html) for an explanation of how type checking handles variance.
 Wide pointer            |  a pointer with additional metadata. See "fat pointer" for more.
 ZST                     |  Zero-Sized Type. A type whose values have size 0 bytes. Since `2^0 = 1`, such types can have exactly one value. For example, `()` (unit) is a ZST. `struct Foo;` is also a ZST. The compiler can do some nice optimizations around ZSTs.
 
diff --git a/src/appendix/stupid-stats.md b/src/appendix/stupid-stats.md
index 842a2a328..a36cac42b 100644
--- a/src/appendix/stupid-stats.md
+++ b/src/appendix/stupid-stats.md
@@ -74,7 +74,7 @@ and a bunch of other crates with the 'librustc_' prefix.
 Next is translation, this translates the AST (and all those side tables) into
 LLVM IR (intermediate representation). We do this by calling into the LLVM
 libraries, rather than actually writing IR directly to a file. The code for
-this is in [librustc_trans](https://github.com/rust-lang/rust/tree/master/src/librustc_trans).
+this is in librustc_trans.
 
 The next phase is running the LLVM backend. This runs LLVM's optimisation passes
 on the generated IR and then generates machine code. The result is object files.
@@ -83,17 +83,22 @@ interface between LLVM and rustc is in [librustc_llvm](https://github.com/rust-l
 
 Finally, we link the object files into an executable. Again we outsource this to
 other programs and it's not really part of the rust compiler. The interface is
-in [librustc_back](https://github.com/rust-lang/rust/tree/master/src/librustc_back)
-(which also contains some things used primarily during translation).
+in librustc_back (which also contains some things used primarily during
+translation).
+
+> NOTE: `librustc_trans` and `librustc_back` no longer exist, and we don't
+> translate AST or HIR directly to LLVM IR anymore.  Instead, see
+> [`librustc_codegen_llvm`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_llvm/index.html)
+> and [`librustc_codegen_utils`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_utils/index.html).
 
 All these phases are coordinated by the driver. To see the exact sequence, look
 at [the `compile_input` function in `librustc_driver`][compile-input].
-The driver handles all the highest level coordination of compilation - 
-    1. handling command-line arguments 
+The driver handles all the highest level coordination of compilation -
+    1. handling command-line arguments
     2. maintaining compilation state (primarily in the `Session`)
     3. calling the appropriate code to run each phase of compilation
     4. handles high level coordination of pretty printing and testing.
-To create a drop-in compiler replacement or a compiler replacement, 
+To create a drop-in compiler replacement or a compiler replacement,
 we leave most of compilation alone and customise the driver using its APIs.
 
 [compile-input]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver/driver/fn.compile_input.html
diff --git a/src/borrow_check/region_inference.md b/src/borrow_check/region_inference.md
index 2cd6066ec..5a09f0bb0 100644
--- a/src/borrow_check/region_inference.md
+++ b/src/borrow_check/region_inference.md
@@ -35,7 +35,7 @@ The MIR-based region analysis consists of two major functions:
   - More details to come, though the [NLL RFC] also includes fairly thorough
     (and hopefully readable) coverage.
 
-[fvb]: appendix/background.html#free-vs-bound
+[fvb]: ../appendix/background.html#free-vs-bound
 [NLL RFC]: http://rust-lang.github.io/rfcs/2094-nll.html
 
 ## Universal regions
@@ -131,7 +131,7 @@ the type of `foo`   the type `bar` expects
 We handle this sort of subtyping by taking the variables that are
 bound in the supertype and **skolemizing** them: this means that we
 replace them with
-[universally quantified](appendix/background.html#quantified)
+[universally quantified](../appendix/background.html#quantified)
 representatives, written like `!1`. We call these regions "skolemized
 regions" – they represent, basically, "some unknown region".
 
@@ -148,7 +148,7 @@ what we wanted.
 
 So let's work through what happens next. To check if two functions are
 subtypes, we check if their arguments have the desired relationship
-(fn arguments are [contravariant](./appendix/background.html#variance), so
+(fn arguments are [contravariant](../appendix/background.html#variance), so
 we swap the left and right here):
 
 ```text
@@ -187,7 +187,7 @@ Here, the root universe would consist of the lifetimes `'static` and
 the same concept to types, in which case the types `Foo` and `T` would
 be in the root universe (along with other global types, like `i32`).
 Basically, the root universe contains all the names that
-[appear free](./appendix/background.html#free-vs-bound) in the body of `bar`.
+[appear free](../appendix/background.html#free-vs-bound) in the body of `bar`.
 
 Now let's extend `bar` a bit by adding a variable `x`:
 
diff --git a/src/const-eval.md b/src/const-eval.md
index 70c946f17..1f801fb22 100644
--- a/src/const-eval.md
+++ b/src/const-eval.md
@@ -35,4 +35,4 @@ integer or fat pointer, it will directly yield the value (via `Value::ByVal` or
 memory allocation (via `Value::ByRef`). This means that the `const_eval`
 function cannot be used to create miri-pointers to the evaluated constant or
 static. If you need that, you need to directly work with the functions in
-[src/librustc_mir/interpret/const_eval.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/interpret/const_eval/).
+[src/librustc_mir/const_eval.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/const_eval/index.html).
diff --git a/src/diag.md b/src/diag.md
index b30ec2eca..936420ab6 100644
--- a/src/diag.md
+++ b/src/diag.md
@@ -304,5 +304,5 @@ lints we want to emit. Instead, the [`BufferedEarlyLintId`] type is used. If you
 are defining a new lint, you will want to add an entry to this enum. Then, add
 an appropriate mapping to the body of [`Lint::from_parser_lint_id`][fplid].
 
-[`BufferedEarlyLintId`]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/early_buffered_lints/struct.BufferedEarlyLintId.html
+[`BufferedEarlyLintId`]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/early_buffered_lints/enum.BufferedEarlyLintId.html
 [fplid]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/lint/struct.Lint.html#from_parser_lint_id
diff --git a/src/mir/index.md b/src/mir/index.md
index ea72decdc..d69606d66 100644
--- a/src/mir/index.md
+++ b/src/mir/index.md
@@ -1,7 +1,7 @@
 # The MIR (Mid-level IR)
 
 MIR is Rust's _Mid-level Intermediate Representation_. It is
-constructed from [HIR](./hir.html). MIR was introduced in
+constructed from [HIR](../hir.html). MIR was introduced in
 [RFC 1211]. It is a radically simplified form of Rust that is used for
 certain flow-sensitive safety checks – notably the borrow checker! –
 and also for optimization and code generation.
@@ -26,7 +26,7 @@ Some of the key characteristics of MIR are:
 - It does not have nested expressions.
 - All types in MIR are fully explicit.
 
-[cfg]: ./appendix/background.html#cfg
+[cfg]: ../appendix/background.html#cfg
 
 ## Key MIR vocabulary
 
@@ -244,4 +244,4 @@ but [you can read about those below](#promoted)).
 [mir]: https://github.com/rust-lang/rust/tree/master/src/librustc/mir
 [mirmanip]: https://github.com/rust-lang/rust/tree/master/src/librustc_mir
 [mir]: https://github.com/rust-lang/rust/tree/master/src/librustc/mir
-[newtype'd]: appendix/glossary.html
+[newtype'd]: ../appendix/glossary.html
diff --git a/src/mir/passes.md b/src/mir/passes.md
index c48ef4576..7dc1249a0 100644
--- a/src/mir/passes.md
+++ b/src/mir/passes.md
@@ -156,7 +156,7 @@ then `mir_const_qualif(D)` would succeed if it came before
 `mir_validated(D)`, but fail otherwise. Therefore, `mir_validated(D)`
 will **force** `mir_const_qualif` before it actually steals, thus
 ensuring that the reads have already happened (remember that
-[queries are memoized](./query.html), so executing a query twice
+[queries are memoized](../query.html), so executing a query twice
 simply loads from a cache the second time):
 
 ```text
@@ -174,4 +174,4 @@ alternatives in [rust-lang/rust#41710].
 [rust-lang/rust#41710]: https://github.com/rust-lang/rust/issues/41710
 [mirtransform]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/
 [`NoLandingPads`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/no_landing_pads/struct.NoLandingPads.html
-[MIR visitor]: mir/visitor.html
+[MIR visitor]: ./visitor.html
diff --git a/src/miri.md b/src/miri.md
index be9587408..a3c7b3ff4 100644
--- a/src/miri.md
+++ b/src/miri.md
@@ -112,7 +112,7 @@ to a pointer to `b`.
 
 Although the main entry point to constant evaluation is the `tcx.const_eval`
 query, there are additional functions in
-[librustc_mir/interpret/const_eval.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/interpret/const_eval/)
+[librustc_mir/const_eval.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/const_eval/index.html)
 that allow accessing the fields of a `Value` (`ByRef` or otherwise). You should
 never have to access an `Allocation` directly except for translating it to the
 compilation target (at the moment just LLVM).
diff --git a/src/profiling/with_perf.md b/src/profiling/with_perf.md
index 7d8276ced..258899400 100644
--- a/src/profiling/with_perf.md
+++ b/src/profiling/with_perf.md
@@ -14,7 +14,7 @@ This is a guide for how to profile rustc with [perf](https://perf.wiki.kernel.or
 - Make a rustup toolchain pointing to that result
   - see [the "build and run" section for instructions][b-a-r]
 
-[b-a-r]: ./how-to-build-and-run.html#toolchain
+[b-a-r]: ../how-to-build-and-run.html#toolchain
   
 ## Gathering a perf profile
 
diff --git a/src/tests/intro.md b/src/tests/intro.md
index bfe084618..4d509f3a8 100644
--- a/src/tests/intro.md
+++ b/src/tests/intro.md
@@ -5,8 +5,8 @@ by the build system (`x.py test`).  The main test harness for testing
 the compiler itself is a tool called compiletest (sources in the
 [`src/tools/compiletest`]). This section gives a brief overview of how
 the testing framework is setup, and then gets into some of the details
-on [how to run tests](./tests/running.html#ui) as well as
-[how to add new tests](./tests/adding.html).
+on [how to run tests](./running.html#ui) as well as
+[how to add new tests](./adding.html).
 
 [`src/tools/compiletest`]: https://github.com/rust-lang/rust/tree/master/src/tools/compiletest
 
@@ -24,7 +24,7 @@ Here is a brief summary of the test suites as of this writing and what
 they mean. In some cases, the test suites are linked to parts of the manual
 that give more details.
 
-- [`ui`](./tests/adding.html#ui) – tests that check the exact
+- [`ui`](./adding.html#ui) – tests that check the exact
   stdout/stderr from compilation and/or running the test
 - `run-pass` – tests that are expected to compile and execute
   successfully (no panics)
@@ -59,7 +59,7 @@ including:
 - **Tidy** – This is a custom tool used for validating source code
   style and formatting conventions, such as rejecting long lines.
   There is more information in the
-  [section on coding conventions](./conventions.html#formatting).
+  [section on coding conventions](../conventions.html#formatting).
 
   Example: `./x.py test src/tools/tidy`
 
@@ -171,7 +171,7 @@ communicate with the server to coordinate running tests (see
 ## Crater
 
 [Crater](https://github.com/rust-lang-nursery/crater) is a tool for compiling
-and running tests for _every_ crate on [crates.io](https://crates.io/) (and a
+and running tests for _every_ crate on [crates.io](https://crates.io) (and a
 few on GitHub). It is mainly used for checking for extent of breakage when
 implementing potentially breaking changes and ensuring lack of breakage by
 running beta vs stable compiler versions.
diff --git a/src/traits/associated-types.md b/src/traits/associated-types.md
index 1972a70e6..b8ac7f8b9 100644
--- a/src/traits/associated-types.md
+++ b/src/traits/associated-types.md
@@ -17,7 +17,7 @@ type can be referenced by the user using an **associated type
 projection** like `<Option<u32> as IntoIterator>::Item`. (Often,
 though, people will use the shorthand syntax `T::Item` – presently,
 that syntax is expanded during
-["type collection"](./type-checking.html) into the explicit form,
+["type collection"](../type-checking.html) into the explicit form,
 though that is something we may want to change in the future.)
 
 [intoiter-item]: https://doc.rust-lang.org/nightly/core/iter/trait.IntoIterator.html#associatedtype.Item
@@ -130,7 +130,7 @@ any given associated item.
 
 Now we are ready to discuss how associated type equality integrates
 with unification. As described in the
-[type inference](./type-inference.html) section, unification is
+[type inference](../type-inference.html) section, unification is
 basically a procedure with a signature like this:
 
 ```text
diff --git a/src/traits/caching.md b/src/traits/caching.md
index 228ff0917..f84539509 100644
--- a/src/traits/caching.md
+++ b/src/traits/caching.md
@@ -24,7 +24,7 @@ On the other hand, if there is no hit, we need to go through the [selection
 process] from scratch. Suppose, we come to the conclusion that the only
 possible impl is this one, with def-id 22:
 
-[selection process]: ./traits/resolution.html#selection
+[selection process]: ./resolution.html#selection
 
 ```rust,ignore
 impl Foo<isize> for usize { ... } // Impl #22
@@ -34,7 +34,7 @@ We would then record in the cache `usize : Foo<$0> => ImplCandidate(22)`. Next
 we would [confirm] `ImplCandidate(22)`, which would (as a side-effect) unify
 `$t` with `isize`.
 
-[confirm]: ./traits/resolution.html#confirmation
+[confirm]: ./resolution.html#confirmation
 
 Now, at some later time, we might come along and see a `usize :
 Foo<$u>`. When skolemized, this would yield `usize : Foo<$0>`, just as
@@ -61,7 +61,7 @@ to be pretty clearly safe and also still retains a very high hit rate
 **TODO**: it looks like `pick_candidate_cache` no longer exists. In
 general, is this section still accurate at all?
 
-[`ParamEnv`]: ./param_env.html
-[`tcx`]: ./ty.html
+[`ParamEnv`]: ../param_env.html
+[`tcx`]: ../ty.html
 [#18290]: https://github.com/rust-lang/rust/issues/18290
 [#22019]: https://github.com/rust-lang/rust/issues/22019
diff --git a/src/traits/canonical-queries.md b/src/traits/canonical-queries.md
index c58fe3696..876c5d8a6 100644
--- a/src/traits/canonical-queries.md
+++ b/src/traits/canonical-queries.md
@@ -3,11 +3,11 @@
 The "start" of the trait system is the **canonical query** (these are
 both queries in the more general sense of the word – something you
 would like to know the answer to – and in the
-[rustc-specific sense](./query.html)).  The idea is that the type
+[rustc-specific sense](../query.html)).  The idea is that the type
 checker or other parts of the system, may in the course of doing their
 thing want to know whether some trait is implemented for some type
 (e.g., is `u32: Debug` true?). Or they may want to
-[normalize some associated type](./traits/associated-types.html).
+[normalize some associated type](./associated-types.html).
 
 This section covers queries at a fairly high level of abstraction. The
 subsections look a bit more closely at how these ideas are implemented
@@ -106,7 +106,7 @@ value for a type variable, that means that this is the **only possible
 instantiation** that you could use, given the current set of impls and
 where-clauses, that would be provable. (Internally within the solver,
 though, they can potentially enumerate all possible answers. See
-[the description of the SLG solver](./traits/slg.html) for details.)
+[the description of the SLG solver](./slg.html) for details.)
 
 The response to a trait query in rustc is typically a
 `Result<QueryResult<T>, NoSolution>` (where the `T` will vary a bit
@@ -132,7 +132,7 @@ we did find. It consists of four parts:
 - **Region constraints:** these are relations that must hold between
   the lifetimes that you supplied as inputs. We'll ignore these here,
   but see the
-  [section on handling regions in traits](./traits/regions.html) for
+  [section on handling regions in traits](./regions.html) for
   more details.
 - **Value:** The query result also comes with a value of type `T`. For
   some specialized queries – like normalizing associated types –
@@ -219,7 +219,7 @@ As a result of this assignment, the type of `u` is forced to be
 `Option<Vec<?V>>`, where `?V` represents the element type of the
 vector. This in turn implies that `?U` is [unified] to `Vec<?V>`.
 
-[unified]: ./type-checking.html
+[unified]: ../type-checking.html
 
 Let's suppose that the type checker decides to revisit the
 "as-yet-unproven" trait obligation we saw before, `Vec<?T>:
diff --git a/src/traits/canonicalization.md b/src/traits/canonicalization.md
index 2cc35d899..df0c4a2b9 100644
--- a/src/traits/canonicalization.md
+++ b/src/traits/canonicalization.md
@@ -6,7 +6,7 @@ from its context. It is a key part of implementing
 to get more context.
 
 Canonicalization is really based on a very simple concept: every
-[inference variable](./type-inference.html#vars) is always in one of
+[inference variable](../type-inference.html#vars) is always in one of
 two states: either it is **unbound**, in which case we don't know yet
 what type it is, or it is **bound**, in which case we do. So to
 isolate some data-structure T that contains types/regions from its
@@ -16,7 +16,7 @@ starting from zero and numbered in a fixed order (left to right, for
 the most part, but really it doesn't matter as long as it is
 consistent).
 
-[cq]: ./traits/canonical-queries.html
+[cq]: ./canonical-queries.html
 
 So, for example, if we have the type `X = (?T, ?U)`, where `?T` and
 `?U` are distinct, unbound inference variables, then the canonical
@@ -41,7 +41,7 @@ trait query: `?A: Foo<'static, ?B>`, where `?A` and `?B` are unbound.
 This query contains two unbound variables, but it also contains the
 lifetime `'static`. The trait system generally ignores all lifetimes
 and treats them equally, so when canonicalizing, we will *also*
-replace any [free lifetime](./appendix/background.html#free-vs-bound) with a
+replace any [free lifetime](../appendix/background.html#free-vs-bound) with a
 canonical variable. Therefore, we get the following result:
 
 ```text
@@ -98,12 +98,12 @@ Remember that substitution S though! We're going to need it later.
 
 OK, now that we have a fresh inference context and an instantiated
 query, we can go ahead and try to solve it. The trait solver itself is
-explained in more detail in [another section](./traits/slg.html), but
+explained in more detail in [another section](./slg.html), but
 suffice to say that it will compute a [certainty value][cqqr] (`Proven` or
 `Ambiguous`) and have side-effects on the inference variables we've
 created. For example, if there were only one impl of `Foo`, like so:
 
-[cqqr]: ./traits/canonical-queries.html#query-response
+[cqqr]: ./canonical-queries.html#query-response
 
 ```rust,ignore
 impl<'a, X> Foo<'a, X> for Vec<X>
diff --git a/src/traits/chalk-overview.md b/src/traits/chalk-overview.md
index e737edcd9..3473a0764 100644
--- a/src/traits/chalk-overview.md
+++ b/src/traits/chalk-overview.md
@@ -131,18 +131,18 @@ See [The SLG Solver][slg].
 
 [rustc-issues]: https://github.com/rust-lang-nursery/rustc-guide/issues
 [chalk]: https://github.com/rust-lang-nursery/chalk
-[lowering-to-logic]: traits/lowering-to-logic.html
-[lowering-rules]: traits/lowering-rules.html
+[lowering-to-logic]: ./lowering-to-logic.html
+[lowering-rules]: ./lowering-rules.html
 [ast]: https://en.wikipedia.org/wiki/Abstract_syntax_tree
 [chalk-ast]: https://github.com/rust-lang-nursery/chalk/blob/master/chalk-parse/src/ast.rs
 [universal quantification]: https://en.wikipedia.org/wiki/Universal_quantification
-[lowering-forall]: ./traits/lowering-to-logic.html#type-checking-generic-functions-beyond-horn-clauses
+[lowering-forall]: ./lowering-to-logic.html#type-checking-generic-functions-beyond-horn-clauses
 [programclause]: https://github.com/rust-lang-nursery/chalk/blob/94a1941a021842a5fcb35cd043145c8faae59f08/src/ir.rs#L721
 [clause]: https://github.com/rust-lang-nursery/chalk/blob/master/GLOSSARY.md#clause
-[goals-and-clauses]: ./traits/goals-and-clauses.html
+[goals-and-clauses]: ./goals-and-clauses.html
 [well-formedness-checks]: https://github.com/rust-lang-nursery/chalk/blob/94a1941a021842a5fcb35cd043145c8faae59f08/src/ir/lowering.rs#L230-L232
-[ir-code]: https://github.com/rust-lang-nursery/chalk/blob/master/src/ir.rs
-[HIR]: hir.html
+[ir-code]: https://github.com/rust-lang-nursery/chalk/tree/master/chalk-ir
+[HIR]: ../hir.html
 [binders-struct]: https://github.com/rust-lang-nursery/chalk/blob/94a1941a021842a5fcb35cd043145c8faae59f08/src/ir.rs#L661
 [rules-environment]: https://github.com/rust-lang-nursery/chalk/blob/94a1941a021842a5fcb35cd043145c8faae59f08/src/rules.rs#L9
-[slg]: ./traits/slg.html
+[slg]: ./slg.html
diff --git a/src/traits/goals-and-clauses.md b/src/traits/goals-and-clauses.md
index 93bafe33f..5aa3755ad 100644
--- a/src/traits/goals-and-clauses.md
+++ b/src/traits/goals-and-clauses.md
@@ -2,7 +2,7 @@
 
 In logic programming terms, a **goal** is something that you must
 prove and a **clause** is something that you know is true. As
-described in the [lowering to logic](./traits/lowering-to-logic.html)
+described in the [lowering to logic](./lowering-to-logic.html)
 chapter, Rust's trait solver is based on an extension of hereditary
 harrop (HH) clauses, which extend traditional Prolog Horn clauses with
 a few new superpowers.
@@ -37,7 +37,7 @@ paper
 ["A Proof Procedure for the Logic of Hereditary Harrop Formulas"][pphhf]
 gives the details.
 
-[pphhf]: ./traits/bibliography.html#pphhf
+[pphhf]: ./bibliography.html#pphhf
 
 <a name="domain-goals"></a>
 
@@ -94,7 +94,7 @@ e.g. `ProjectionEq<T as Iterator>::Item = u8`
 
 The given associated type `Projection` is equal to `Type`; this can be proved
 with either normalization or using skolemized types. See [the section
-on associated types](./traits/associated-types.html).
+on associated types](./associated-types.html).
 
 #### Normalize(Projection -> Type)
 e.g. `ProjectionEq<T as Iterator>::Item -> u8`
@@ -102,12 +102,12 @@ e.g. `ProjectionEq<T as Iterator>::Item -> u8`
 The given associated type `Projection` can be [normalized][n] to `Type`.
 
 As discussed in [the section on associated
-types](./traits/associated-types.html), `Normalize` implies `ProjectionEq`,
+types](./associated-types.html), `Normalize` implies `ProjectionEq`,
 but not vice versa. In general, proving `Normalize(<T as Trait>::Item -> U)`
 also requires proving `Implemented(T: Trait)`.
 
-[n]: ./traits/associated-types.html#normalize
-[at]: ./traits/associated-types.html
+[n]: ./associated-types.html#normalize
+[at]: ./associated-types.html
 
 #### FromEnv(TraitRef), FromEnv(Projection = Type)
 e.g. `FromEnv(Self: Add<i32>)`
@@ -212,7 +212,7 @@ In addition to auto traits, `WellFormed` predicates are co-inductive.
 These are used to achieve a similar "enumerate all the cases" pattern,
 as described in the section on [implied bounds].
 
-[implied bounds]: ./traits/lowering-rules.html#implied-bounds
+[implied bounds]: ./lowering-rules.html#implied-bounds
 
 ## Incomplete chapter
 
diff --git a/src/traits/index.md b/src/traits/index.md
index c070d1b88..c5afb280b 100644
--- a/src/traits/index.md
+++ b/src/traits/index.md
@@ -4,7 +4,7 @@
 [process of being implemented][wg]; this chapter serves as a kind of
 in-progress design document. If you would prefer to read about how the
 current trait solver works, check out
-[this other chapter](./traits/resolution.html). (By the way, if you
+[this other chapter](./resolution.html). (By the way, if you
 would like to help in hacking on the new solver, you will find
 instructions for getting involved in the
 [Traits Working Group tracking issue][wg].) 🚧
@@ -13,20 +13,20 @@ instructions for getting involved in the
 
 Trait solving is based around a few key ideas:
 
-- [Lowering to logic](./traits/lowering-to-logic.html), which expresses
+- [Lowering to logic](./lowering-to-logic.html), which expresses
   Rust traits in terms of standard logical terms.
-  - The [goals and clauses](./traits/goals-and-clauses.html) chapter
+  - The [goals and clauses](./goals-and-clauses.html) chapter
     describes the precise form of rules we use, and
-    [lowering rules](./traits/lowering-rules.html) gives the complete set of
+    [lowering rules](./lowering-rules.html) gives the complete set of
     lowering rules in a more reference-like form.
-- [Canonical queries](./traits/canonical-queries.html), which allow us
+- [Canonical queries](./canonical-queries.html), which allow us
   to solve trait problems (like "is `Foo` implemented for the type
   `Bar`?") once, and then apply that same result independently in many
   different inference contexts.
-- [Lazy normalization](./traits/associated-types.html), which is the
+- [Lazy normalization](./associated-types.html), which is the
   technique we use to accommodate associated types when figuring out
   whether types are equal.
-- [Region constraints](./traits/regions.html), which are accumulated
+- [Region constraints](./regions.html), which are accumulated
   during trait solving but mostly ignored. This means that trait
   solving effectively ignores the precise regions involved, always –
   but we still remember the constraints on them so that those
diff --git a/src/traits/lowering-module.md b/src/traits/lowering-module.md
index 030e19860..c9c4accc1 100644
--- a/src/traits/lowering-module.md
+++ b/src/traits/lowering-module.md
@@ -1,7 +1,7 @@
 # The lowering module in rustc
 
 The program clauses described in the
-[lowering rules](./traits/lowering-rules.html) section are actually
+[lowering rules](./lowering-rules.html) section are actually
 created in the [`rustc_traits::lowering`][lowering] module.
 
 [lowering]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_traits/lowering/
@@ -16,7 +16,7 @@ query is invoked on a `DefId` that identifies something like a trait,
 an impl, or an associated item definition. It then produces and
 returns a vector of program clauses.
 
-[query]: ./query.html
+[query]: ../query.html
 
 <a name="unit-tests"></a>
 
diff --git a/src/traits/lowering-rules.md b/src/traits/lowering-rules.md
index 41c9625f6..218164c0f 100644
--- a/src/traits/lowering-rules.md
+++ b/src/traits/lowering-rules.md
@@ -4,8 +4,8 @@ This section gives the complete lowering rules for Rust traits into
 [program clauses][pc]. It is a kind of reference. These rules
 reference the [domain goals][dg] defined in an earlier section.
 
-[pc]: ./traits/goals-and-clauses.html
-[dg]: ./traits/goals-and-clauses.html#domain-goals
+[pc]: ./goals-and-clauses.html
+[dg]: ./goals-and-clauses.html#domain-goals
 
 ## Notation
 
@@ -16,7 +16,7 @@ The nonterminal `Ai` is used to mean some generic *argument*, which
 might be a lifetime like `'a` or a type like `Vec<A>`.
 
 When defining the lowering rules, we will give goals and clauses in
-the [notation given in this section](./traits/goals-and-clauses.html).
+the [notation given in this section](./goals-and-clauses.html).
 We sometimes insert "macros" like `LowerWhereClause!` into these
 definitions; these macros reference other sections within this chapter.
 
@@ -141,7 +141,7 @@ This `WellFormed` rule states that `T: Trait` is well-formed if (a)
 `T: Trait` is implemented and (b) all the where-clauses declared on
 `Trait` are well-formed (and hence they are implemented). Remember
 that the `WellFormed` predicate is
-[coinductive](./traits/goals-and-clauses.html#coinductive); in this
+[coinductive](./goals-and-clauses.html#coinductive); in this
 case, it is serving as a kind of "carrier" that allows us to enumerate
 all the where clauses that are transitively implied by `T: Trait`.
 
@@ -266,7 +266,7 @@ where WC
 
 We will produce a number of program clauses. The first two define
 the rules by which `ProjectionEq` can succeed; these two clauses are discussed
-in detail in the [section on associated types](./traits/associated-types.html),
+in detail in the [section on associated types](./associated-types.html),
 but reproduced here for reference:
 
 ```text
diff --git a/src/traits/lowering-to-logic.md b/src/traits/lowering-to-logic.md
index cf8c1c25a..a0490adf3 100644
--- a/src/traits/lowering-to-logic.md
+++ b/src/traits/lowering-to-logic.md
@@ -170,8 +170,8 @@ example Gopalan Nadathur's excellent
 ["A Proof Procedure for the Logic of Hereditary Harrop Formulas"][pphhf]
 in [the bibliography].
 
-[the bibliography]: ./traits/bibliography.html
-[pphhf]: ./traits/bibliography.html#pphhf
+[the bibliography]: ./bibliography.html
+[pphhf]: ./bibliography.html#pphhf
 
 It turns out that supporting FOHH is not really all that hard. And
 once we are able to do that, we can easily describe the type-checking
diff --git a/src/traits/resolution.md b/src/traits/resolution.md
index 987d9a28d..2ba451677 100644
--- a/src/traits/resolution.md
+++ b/src/traits/resolution.md
@@ -6,7 +6,7 @@ some non-obvious things.
 **Note:** This chapter (and its subchapters) describe how the trait
 solver **currently** works. However, we are in the process of
 designing a new trait solver. If you'd prefer to read about *that*,
-see [*this* traits chapter](./traits/index.html).
+see [*this* traits chapter](./index.html).
 
 ## Major concepts
 
@@ -220,7 +220,7 @@ in that list. If so, it is considered satisfied. More precisely, we
 want to check whether there is a where-clause obligation that is for
 the same trait (or some subtrait) and which can match against the obligation.
 
-[parameter environment]: ./param_env.html
+[parameter environment]: ../param_env.html
 
 Consider this simple example: