Fix all the links!

Author: mark-i-m

book.toml

@@ -9,4 +9,4 @@ description = "A guide to developing rustc"
 
 [output.linkcheck]
 follow-web-links = true
-exclude = [ "crates\\.io" ]
+exclude = [ "crates\\.io", "gcc\\.godbolt\\.org" ]

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/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/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/tests/intro.md

@@ -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/chalk-overview.md

@@ -141,7 +141,7 @@ See [The SLG Solver][slg].
 [clause]: https://github.com/rust-lang-nursery/chalk/blob/master/GLOSSARY.md#clause
 [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
+[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