Fix broken links

src/appendix/glossary.md

@@ -23,7 +23,7 @@ Term                                                  | Meaning
 <span id="double-ptr">double pointer</span>    &nbsp; |  A pointer with additional metadata. See "fat pointer" for more.
 <span id="drop-glue">drop glue</span>          &nbsp; |  (internal) compiler-generated instructions that handle calling the destructors (`Drop`) for data types.
 <span id="dst">DST</span>                      &nbsp; |  Short for Dynamically-Sized Type, this is 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]`).
-<span id="ebl">early-bound lifetime</span>     &nbsp; |  A lifetime region that is substituted at its definition site. Bound in an item's `Generics` and substituted using a `Substs`. Contrast with **late-bound lifetime**. ([see more](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.RegionKind.html#bound-regions))
+<span id="ebl">early-bound lifetime</span>     &nbsp; |  A lifetime region that is substituted at its definition site. Bound in an item's `Generics` and substituted using a `Substs`. Contrast with **late-bound lifetime**. ([see more](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_type_ir/sty/enum.RegionKind.html#bound-regions))
 <span id="empty-type">empty type</span>        &nbsp; |  see "uninhabited type".
 <span id="fat-ptr">fat pointer</span>          &nbsp; |  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".
 <span id="free-var">free variable</span>       &nbsp; |  A "free variable" is one that is not bound within an expression or term; see [the background chapter for more](./background.md#free-vs-bound)
@@ -42,7 +42,7 @@ Term                                                  | Meaning
 <span id="irlo">IRLO</span>                    &nbsp; |  `IRLO` or `irlo` is sometimes used as an abbreviation for [internals.rust-lang.org](https://internals.rust-lang.org).
 <span id="item">item</span>                    &nbsp; |  A kind of "definition" in the language, such as a static, const, use statement, module, struct, etc. Concretely, this corresponds to the `Item` type.
 <span id="lang-item">lang item</span>          &nbsp; |  Items that represent concepts intrinsic to the language itself, such as special built-in traits like `Sync` and `Send`; or traits representing operations such as `Add`; or functions that are called by the compiler. ([see more](https://doc.rust-lang.org/1.9.0/book/lang-items.html))
-<span id="lbl">late-bound lifetime</span>      &nbsp; |  A lifetime region that is substituted at its call site. Bound in a HRTB and substituted by specific functions in the compiler, such as `liberate_late_bound_regions`. Contrast with **early-bound lifetime**. ([see more](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.RegionKind.html#bound-regions))
+<span id="lbl">late-bound lifetime</span>      &nbsp; |  A lifetime region that is substituted at its call site. Bound in a HRTB and substituted by specific functions in the compiler, such as `liberate_late_bound_regions`. Contrast with **early-bound lifetime**. ([see more](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_type_ir/sty/enum.RegionKind.html#bound-regions))
 <span id="local-crate">local crate</span>      &nbsp; |  The crate currently being compiled. This is in contrast to "upstream crates" which refer to dependencies of the local crate.
 <span id="lto">LTO</span>                      &nbsp; |  Short for Link-Time Optimizations, this is 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].
 <span id="llvm">[LLVM]</span>                  &nbsp; |  (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 outputs LLVM IR and use LLVM to compile to all the platforms LLVM supports.

src/borrow_check/region_inference/lifetime_parameters.md

@@ -43,8 +43,8 @@ only variant of [`ty::RegionKind`] that we use is the [`ReVar`]
 variant. These region variables are broken into two major categories,
 based on their index:
 
-[`ty::RegionKind`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.RegionKind.html
-[`ReVar`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.RegionKind.html#variant.ReVar
+[`ty::RegionKind`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_type_ir/sty/enum.RegionKind.html
+[`ReVar`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_type_ir/sty/enum.RegionKind.html#variant.ReVar
 
 - 0..N: universal regions -- the ones we are discussing here. In this
   case, the code must be correct with respect to any value of those

src/constants.md

@@ -78,5 +78,5 @@ the constant doesn't use them in any way. This can cause
 
 [`ty::Const`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.Const.html
 [`ty::ConstKind`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.ConstKind.html
-[`ty::TyKind`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.TyKind.html
+[`ty::TyKind`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_type_ir/sty/enum.TyKind.html
 [pcg-unused-substs]: https://github.com/rust-lang/project-const-generics/issues/33

src/implementing_new_features.md

@@ -33,7 +33,7 @@ like this; for example, the compiler team recommends
 filing a Major Change Proposal ([MCP][mcp]) as a lightweight way to
 garner support and feedback without requiring full consensus.
 
-[mcp]: compiler/mcp.md#public-facing-changes-require-rfcbot-fcp
+[mcp]: https://forge.rust-lang.org/compiler/mcp.html#public-facing-changes-require-rfcbot-fcp
 
 You don't need to have the implementation fully ready for r+ to propose an FCP,
 but it is generally a good idea to have at least a proof

src/llvm-coverage-instrumentation.md

@@ -299,11 +299,10 @@ $ ./x.py test tests/run-make-fulldeps/coverage --bless
 ```
 
 [mir-opt-test]: https://github.com/rust-lang/rust/blob/master/tests/mir-opt/instrument_coverage.rs
-[coverage-test-samples]: https://github.com/rust-lang/rust/tree/master/tests/run-make-fulldeps/coverage
-[`coverage-reports`]: https://github.com/rust-lang/rust/tree/master/tests/run-make-fulldeps/coverage-reports
-[`coverage-spanview`]: https://github.com/rust-lang/rust/tree/master/tests/run-make-fulldeps/coverage-spanview
+[coverage-test-samples]: https://github.com/rust-lang/rust/tree/master/tests/run-make/coverage
+[`coverage-reports`]: https://github.com/rust-lang/rust/tree/master/tests/run-make/coverage-reports
 [spanview-debugging]: compiler-debugging.md#viewing-spanview-output
-[`coverage-llvmir`]: https://github.com/rust-lang/rust/tree/master/tests/run-make-fulldeps/coverage-llvmir
+[`coverage-llvmir`]: https://github.com/rust-lang/rust/tree/master/tests/run-make/coverage-llvmir
 
 ## Implementation Details of the `InstrumentCoverage` MIR Pass
 

src/mir/visitor.md

@@ -37,10 +37,10 @@ code that will execute whenever a `foo` is found. If you want to
 recursively walk the contents of the `foo`, you then invoke the
 `super_foo` method. (NB. You never want to override `super_foo`.)
 
-A very simple example of a visitor can be found in [`LocalUseCounter`].
-By implementing `visit_local` method, this visitor counts how many times each local is used.
+A very simple example of a visitor can be found in [`LocalUseVisitor`].
+By implementing `visit_local` method, this visitor counts how many times each local is mutably used.
 
-[`LocalUseCounter`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_transform/simplify_try/struct.LocalUseCounter.html
+[`LocalUseVisitor`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_transform/const_debuginfo/struct.LocalUseVisitor.html
 
 ## Traversal
 

src/profiling/with_perf.md

@@ -90,14 +90,15 @@ You can also use that same command to use cachegrind or other profiling tools.
 
 If you prefer to run things manually, that is also possible. You first
 need to find the source for the test you want. Sources for the tests
-are found in [the `collector/benchmarks` directory][dir]. So let's go
-into the directory of a specific test; we'll use `clap-rs` as an
-example:
+are found in [the `collector/compile-benchmarks` directory][compile-time dir]
+and [the `collector/runtime-benchmarks` directory][runtime dir]. So let's
+go into the directory of a specific test; we'll use `clap-rs` as an example:
 
-[dir]: https://github.com/rust-lang/rustc-perf/tree/master/collector/benchmarks
+[compile-time dir]: https://github.com/rust-lang/rustc-perf/tree/master/collector/compile-benchmarks
+[runtime dir]: https://github.com/rust-lang/rustc-perf/tree/master/collector/runtime-benchmarks
 
 ```bash
-cd collector/benchmarks/clap-rs
+cd collector/compile-benchmarks/clap-3.1.6
 ```
 
 In this case, let's say we want to profile the `cargo check`

src/solve/the-solver.md

@@ -12,6 +12,6 @@ While the actual solver is not fully pure to deal with overflow and cycles, we a
 going to defer that for now.
 
 To deal with inference variables and to improve caching, we use
-[canonicalization](/canonicalization.html).
+[canonicalization](./canonicalization.md).
 
-TODO: write the remaining code for this as well.
+TODO: write the remaining code for this as well.

src/solve/trait-solving.md

@@ -2,7 +2,7 @@
 
 This chapter describes how trait solving works with the new WIP solver located in
 [`rustc_trait_selection/solve`][solve]. Feel free to also look at the docs for
-[the current solver](../traits/resolution.hmtl) and [the chalk solver](./chalk.html)
+[the current solver](../traits/resolution.md) and [the chalk solver](../traits/chalk.md)
 can be found separately.
 
 ## Core concepts
@@ -29,7 +29,7 @@ have to prove and the `param_env` in which this predicate has to hold.
 We prove goals by checking whether each possible [`Candidate`] applies for the given goal by
 recursively proving its nested goals. For a list of possible candidates with examples, look at
 [`CandidateSource`]. The most important candidates are `Impl` candidates, i.e. trait implementations
-written by the user,  and `ParamEnv` candidates, i.e. assumptions in our current environment.
+written by the user, and `ParamEnv` candidates, i.e. assumptions in our current environment.
 
 Looking at the above example, to prove `Vec<T>: Clone` we first use
 `impl<T: Clone> Clone for Vec<T>`. To use this impl we have to prove the nested
@@ -64,7 +64,7 @@ We can however get overflow as in the following snippet:
 fn foo<T: Trait>(x: )
 ```
 
-### 3. Trait goals in empty environments are proven by a unique impl.
+### 3. Trait goals in empty environments are proven by a unique impl
 
 If a trait goal holds with an empty environment, there is a unique `impl`,
 either user-defined or builtin, which is used to prove that goal.
@@ -110,5 +110,5 @@ Two types being equal in the type system must mean that they have the same `Type
 [`Goal`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_trait_selection/solve/struct.Goal.html
 [`Predicate`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.Predicate.html
 [`Candidate`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_trait_selection/solve/assembly/struct.Candidate.html
-[`CandidateSource`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_trait_selection/solve/trait_goals/enum.CandidateSource.html
-[`CanonicalResponse`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_trait_selection/solve/type.CanonicalResponse.html
+[`CandidateSource`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_trait_selection/solve/assembly/enum.CandidateSource.html
+[`CanonicalResponse`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_trait_selection/solve/type.CanonicalResponse.html

src/ty.md

@@ -133,7 +133,7 @@ the `ty::Ty` to be a thin pointer-like
 type. This allows us to do cheap comparisons for equality, along with the other
 benefits of interning.
 
-[tykind]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.TyKind.html
+[tykind]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_type_ir/sty/enum.TyKind.html
 
 ## Allocating and working with types
 
@@ -251,16 +251,16 @@ There are many variants on the `TyKind` enum, which you can see by looking at it
 - [**And many more**...][kindvars]
 
 [wikiadt]: https://en.wikipedia.org/wiki/Algebraic_data_type
-[kindadt]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.TyKind.html#variant.Adt
-[kindforeign]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.TyKind.html#variant.Foreign
-[kindstr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.TyKind.html#variant.Str
-[kindslice]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.TyKind.html#variant.Slice
-[kindarray]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.TyKind.html#variant.Array
-[kindrawptr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.TyKind.html#variant.RawPtr
-[kindref]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.TyKind.html#variant.Ref
-[kindparam]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.TyKind.html#variant.Param
-[kinderr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.TyKind.html#variant.Error
-[kindvars]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.TyKind.html#variants
+[kindadt]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_type_ir/sty/enum.TyKind.html#variant.Adt
+[kindforeign]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_type_ir/sty/enum.TyKind.html#variant.Foreign
+[kindstr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_type_ir/sty/enum.TyKind.html#variant.Str
+[kindslice]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_type_ir/sty/enum.TyKind.html#variant.Slice
+[kindarray]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_type_ir/sty/enum.TyKind.html#variant.Array
+[kindrawptr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_type_ir/sty/enum.TyKind.html#variant.RawPtr
+[kindref]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_type_ir/sty/enum.TyKind.html#variant.Ref
+[kindparam]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_type_ir/sty/enum.TyKind.html#variant.Param
+[kinderr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_type_ir/sty/enum.TyKind.html#variant.Error
+[kindvars]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_type_ir/sty/enum.TyKind.html#variants
 
 ## Import conventions