Update to mdbook 0.2

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`.

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" ]

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

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>

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

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

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`:
 

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).

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

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

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

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).

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
 

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.

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

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

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>:

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>