diff --git a/README.md b/README.md
index 098971862..4a8c975fb 100644
--- a/README.md
+++ b/README.md
@@ -10,7 +10,7 @@ some new part of the compiler that they haven't worked on before.
 
 You may also find the rustdocs [for the compiler itself][rustdocs] useful.
 
-[rustdocs]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/
+[rustdocs]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/
 
 ### Contributing to the guide
 
diff --git a/src/about-this-guide.md b/src/about-this-guide.md
index 0519099b3..0882c40c0 100644
--- a/src/about-this-guide.md
+++ b/src/about-this-guide.md
@@ -26,6 +26,6 @@ You might also find the following sites useful:
   of the team procedures, active working groups, and the team calendar.
 
 [GitHub repository]: https://github.com/rust-lang/rustc-dev-guide/
-[Rustc API docs]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/
+[Rustc API docs]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/
 [Forge]: https://forge.rust-lang.org/
 [compiler-team]: https://github.com/rust-lang/compiler-team/
diff --git a/src/appendix/code-index.md b/src/appendix/code-index.md
index 0321da195..a4b18ecc0 100644
--- a/src/appendix/code-index.md
+++ b/src/appendix/code-index.md
@@ -16,20 +16,20 @@ Item            |  Kind    | Short description           | Chapter            |
 `HirId` | struct | One of four types of HIR node identifiers | [Identifiers in the HIR] | [src/librustc_hir/hir_id.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/hir_id/struct.HirId.html)
 `NodeId` | struct | One of four types of HIR node identifiers. Being phased out | [Identifiers in the HIR] | [src/librustc_ast/ast.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/node_id/struct.NodeId.html)
 `P` | struct | An owned immutable smart pointer. By contrast, `&T` is not owned, and `Box<T>` is not immutable. | None | [src/librustc_ast/ptr.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/ptr/struct.P.html)
-`ParamEnv` | struct | Information about generic parameters or `Self`, useful for working with associated or generic items | [Parameter Environment] | [src/librustc/ty/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.ParamEnv.html)
+`ParamEnv` | struct | Information about generic parameters or `Self`, useful for working with associated or generic items | [Parameter Environment] | [src/librustc_middle/ty/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.ParamEnv.html)
 `ParseSess` | struct | This struct contains information about a parsing session | [The parser] | [src/librustc_session/parse/parse.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/parse/struct.ParseSess.html)
 `Query` | struct | Represents the result of query to the `Compiler` interface and allows stealing, borrowing, and returning the results of compiler passes. | [The Rustc Driver and Interface] | [src/librustc_interface/queries.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/queries/struct.Query.html)
 `Rib` | struct | Represents a single scope of names | [Name resolution] | [src/librustc_resolve/lib.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_resolve/late/struct.Rib.html)
-`Session` | struct | The data associated with a compilation session | [The parser], [The Rustc Driver and Interface] | [src/librustc/session/mod.html](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/struct.Session.html)
+`Session` | struct | The data associated with a compilation session | [The parser], [The Rustc Driver and Interface] | [src/librustc_middle/session/mod.html](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/struct.Session.html)
 `SourceFile` | struct | Part of the `SourceMap`. Maps AST nodes to their source code for a single source file. Was previously called FileMap | [The parser] | [src/librustc_span/lib.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/struct.SourceFile.html)
 `SourceMap` | struct | Maps AST nodes to their source code. It is composed of `SourceFile`s. Was previously called CodeMap | [The parser] | [src/librustc_span/source_map.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/source_map/struct.SourceMap.html)
 `Span` | struct  | A location in the user's source code, used for error reporting primarily | [Emitting Diagnostics] | [src/librustc_span/span_encoding.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/struct.Span.html)
 `StringReader` | struct | This is the lexer used during parsing. It consumes characters from the raw source code being compiled and produces a series of tokens for use by the rest of the parser | [The parser] |  [src/librustc_parse/lexer/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/lexer/struct.StringReader.html)
 `rustc_ast::token_stream::TokenStream` | struct | An abstract sequence of tokens, organized into `TokenTree`s | [The parser], [Macro expansion] | [src/librustc_ast/tokenstream.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/tokenstream/struct.TokenStream.html)
-`TraitDef` | struct | This struct contains a trait's definition with type information | [The `ty` modules] |  [src/librustc/ty/trait_def.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/trait_def/struct.TraitDef.html)
-`TraitRef` | struct | The combination of a trait and its input types (e.g. `P0: Trait<P1...Pn>`) | [Trait Solving: Goals and Clauses], [Trait Solving: Lowering impls]  |  [src/librustc/ty/sty.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.TraitRef.html)
-`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<'tcx>` | struct | 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)
+`TraitDef` | struct | This struct contains a trait's definition with type information | [The `ty` modules] |  [src/librustc_middle/ty/trait_def.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/trait_def/struct.TraitDef.html)
+`TraitRef` | struct | The combination of a trait and its input types (e.g. `P0: Trait<P1...Pn>`) | [Trait Solving: Goals and Clauses], [Trait Solving: Lowering impls]  |  [src/librustc_middle/ty/sty.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TraitRef.html)
+`Ty<'tcx>` | struct | This is the internal representation of a type used for type checking | [Type checking] | [src/librustc_middle/ty/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/type.Ty.html)
+`TyCtxt<'tcx>` | struct | 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_middle/ty/context.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TyCtxt.html)
 
 [The HIR]: ../hir.html
 [Identifiers in the HIR]: ../hir.html#hir-id
diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md
index 9b208b8c0..39913a3f7 100644
--- a/src/appendix/glossary.md
+++ b/src/appendix/glossary.md
@@ -18,11 +18,11 @@ CTFE                    |  Short for Compile-Time Function Evaluation, this is t
 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](../queries/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`.
+DefId                   |  An index identifying a definition (see `librustc_middle/hir/def_id.rs`). Uniquely identifies a `DefPath`.
 Double pointer          |  A pointer with additional metadata. See "fat pointer" for more.
 drop glue               |  (internal) compiler-generated instructions that handle calling the destructors (`Drop`) for data types.
 DST                     |  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]`).
-early-bound lifetime    |  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/ty/enum.RegionKind.html#bound-regions))
+early-bound lifetime    |  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))
 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](./background.html#free-vs-bound)
@@ -33,13 +33,13 @@ HIR Map                 |  The HIR map, accessible via tcx.hir, allows you to qu
 ICE                     |  Short for internal compiler error, this is when the compiler crashes.
 ICH                     |  Short for incremental compilation hash, these are used as fingerprints for things such as HIR and crate metadata, to check if changes have been made. This is useful in incremental compilation to see if part of a crate has changed and should be recompiled.
 inference variable      |  When doing type or region inference, an "inference variable" is a kind of special type/region that represents what you are trying to infer. Think of X in algebra. For example, if we are trying to infer the type of a variable in a program, we create an inference variable to represent that unknown type.
-infcx                   |  The inference context (see `librustc/infer`)
+infcx                   |  The inference context (see `librustc_middle/infer`)
 intern                  |  Interning refers to storing certain frequently-used constant data, such as strings, and then referring to the data by an identifier (e.g. a `Symbol`) rather than the data itself, to reduce memory usage and number of allocations. See [this chapter](../memory.md) for more info.
 IR                      |  Short for Intermediate Representation, a general term in compilers. During compilation, the code is transformed from raw source (ASCII text) to various IRs. In Rust, these are primarily HIR, MIR, and LLVM IR. Each IR is well-suited for some set of computations. For example, MIR is well-suited for the borrow checker, and LLVM IR is well-suited for codegen because LLVM accepts it.
 IRLO                    |  `IRLO` or `irlo` is sometimes used as an abbreviation for [internals.rust-lang.org](https://internals.rust-lang.org).
 item                    |  A kind of "definition" in the language, such as a static, const, use statement, module, struct, etc. Concretely, this corresponds to the `Item` type.
 lang item               |  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))
-late-bound lifetime     |  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/ty/enum.RegionKind.html#bound-regions))
+late-bound lifetime     |  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))
 local crate             |  The crate currently being compiled.
 LTO                     |  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].
 [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 outputs LLVM IR and use LLVM to compile to all the platforms LLVM supports.
diff --git a/src/appendix/stupid-stats.md b/src/appendix/stupid-stats.md
index 7453f4424..a07956f0f 100644
--- a/src/appendix/stupid-stats.md
+++ b/src/appendix/stupid-stats.md
@@ -17,7 +17,7 @@ complex make project or Cargo build, etc. That could be a lot of work;
 rustc, like most compilers, takes a large number of command line arguments which
 can affect compilation in complex and interacting ways. Emulating all of this
 behaviour in your tool is annoying at best, especically if you are making many
-of the same calls into librustc that the compiler is.
+of the same calls into librustc_middle that the compiler is.
 
 The kind of things I have in mind are tools like rustdoc or a future rustfmt.
 These want to operate as closely as possible to real compilation, but have
@@ -27,7 +27,7 @@ custom code generation phase after macro expansion, then creating a new tool
 should be easier than forking the compiler (and keeping it up to date as the
 compiler evolves).
 
-I have gradually been trying to improve the API of librustc to make creating a
+I have gradually been trying to improve the API of librustc_middle to make creating a
 drop-in tool easier to produce (many others have also helped improve these
 interfaces over the same time frame). It is now pretty simple to make a tool
 which is as close to rustc as you want it to be. In this tutorial I'll show
@@ -73,7 +73,7 @@ checking, borrow checking, type and lifetime inference, trait selection, method
 selection, linting, and so forth. Most error detection is done in this phase
 (although parse errors are found during parsing). The 'output' of this phase is
 a bunch of side tables containing semantic information about the source program.
-The analysis code is in [librustc](https://github.com/rust-lang/rust/tree/master/src/librustc)
+The analysis code is in [librustc_middle](https://github.com/rust-lang/rust/tree/master/src/librustc_middle)
 and a bunch of other crates with the 'librustc_' prefix.
 
 Next is translation, this translates the AST (and all those side tables) into
diff --git a/src/borrow_check/moves_and_initialization/move_paths.md b/src/borrow_check/moves_and_initialization/move_paths.md
index 9b8cbd47a..2c7c73038 100644
--- a/src/borrow_check/moves_and_initialization/move_paths.md
+++ b/src/borrow_check/moves_and_initialization/move_paths.md
@@ -28,7 +28,7 @@ they are indexed in ways that enable us to do move analysis more
 efficiently.
 
 [`MovePath`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/move_paths/struct.MovePath.html
-[`Place`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/struct.Place.html
+[`Place`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/struct.Place.html
 
 ## Move path indices
 
@@ -105,7 +105,7 @@ of [`MoveData`]. There are two different methods:
   
 [`find`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/move_paths/struct.MovePathLookup.html#method.find
 [`find_local`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/move_paths/struct.MovePathLookup.html#method.find_local
-[`mir::Local`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/struct.Local.html
+[`mir::Local`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/struct.Local.html
 [`LookupResult`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/move_paths/enum.LookupResult.html
 
 ## Cross-references
@@ -118,10 +118,10 @@ they are also structured into a tree. So for example if you have the
 you might iterate to find the path `a.b.c` (here you are iterating
 just over the paths that are **actually referenced** in the source,
 not all **possible** paths that could have been referenced). These
-references are used for example in the [`has_any_child_of`] function,
-which checks whether the dataflow results contain a value for the
-given move-path (e.g., `a.b`) or any child of that move-path (e.g.,
-`a.b.c`).
+references are used for example in the
+[`find_in_move_path_or_its_descendants`] function, which determines
+whether a move-path (e.g., `a.b`) or any child of that move-path 
+(e.g.,`a.b.c`) matches a given predicate.
 
-[`Place`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/struct.Place.html
-[`has_any_child_of`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/at_location/struct.FlowAtLocation.html#method.has_any_child_of
+[`Place`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/struct.Place.html
+[`find_in_move_path_or_its_descendants`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/move_paths/struct.MoveData.html#method.find_in_move_path_or_its_descendants
diff --git a/src/borrow_check/region_inference.md b/src/borrow_check/region_inference.md
index d0da861db..3b844b97c 100644
--- a/src/borrow_check/region_inference.md
+++ b/src/borrow_check/region_inference.md
@@ -219,7 +219,7 @@ Here are some of the fields of the struct:
 
 [`constraints`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/region_infer/struct.RegionInferenceContext.html#structfield.constraints
 [`liveness_constraints`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/region_infer/struct.RegionInferenceContext.html#structfield.liveness_constraints
-[`location`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/struct.Location.html
+[`location`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/struct.Location.html
 [`universal_regions`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/region_infer/struct.RegionInferenceContext.html#structfield.universal_regions
 [`universal_region_relations`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/region_infer/struct.RegionInferenceContext.html#structfield.universal_region_relations
 [`type_tests`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/region_infer/struct.RegionInferenceContext.html#structfield.type_tests
diff --git a/src/borrow_check/region_inference/lifetime_parameters.md b/src/borrow_check/region_inference/lifetime_parameters.md
index 4086b71ef..9d6b229ef 100644
--- a/src/borrow_check/region_inference/lifetime_parameters.md
+++ b/src/borrow_check/region_inference/lifetime_parameters.md
@@ -41,8 +41,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/ty/enum.RegionKind.html
-[`ReVar`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.RegionKind.html#variant.ReVar
+[`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
 
 - 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
diff --git a/src/borrow_check/two_phase_borrows.md b/src/borrow_check/two_phase_borrows.md
index f036c3a8c..ad17bbb66 100644
--- a/src/borrow_check/two_phase_borrows.md
+++ b/src/borrow_check/two_phase_borrows.md
@@ -73,10 +73,10 @@ The activation points are found using the [`GatherBorrows`] visitor. The
 [`BorrowData`] then holds both the reservation and activation points for the
 borrow.
 
-[`AutoBorrow`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/adjustment/enum.AutoBorrow.html
+[`AutoBorrow`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/adjustment/enum.AutoBorrow.html
 [converted]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_build/hair/cx/expr/trait.ToBorrowKind.html#method.to_borrow_kind
-[`BorrowKind`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/enum.BorrowKind.html
-[`GatherBorrows`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/visit/trait.Visitor.html#method.visit_local
+[`BorrowKind`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/enum.BorrowKind.html
+[`GatherBorrows`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/visit/trait.Visitor.html#method.visit_local
 [`BorrowData`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/borrow_set/struct.BorrowData.html
 
 ## Checking two-phase borrows
diff --git a/src/bug-fix-procedure.md b/src/bug-fix-procedure.md
index 55bc86859..b4159097c 100644
--- a/src/bug-fix-procedure.md
+++ b/src/bug-fix-procedure.md
@@ -230,6 +230,8 @@ lint name is mentioned (in the compiler, we use the upper-case name, and a macro
 automatically generates the lower-case string; so searching for
 `overlapping_inherent_impls` would not find much).
 
+> NOTE: these exact files don't exist anymore, but the procedure is still the same.
+
 #### Remove the lint.
 
 The first reference you will likely find is the lint definition [in
diff --git a/src/building/compiler-documenting.md b/src/building/compiler-documenting.md
index 16df10f72..68c9fd227 100644
--- a/src/building/compiler-documenting.md
+++ b/src/building/compiler-documenting.md
@@ -49,4 +49,4 @@ documentation for internal compiler items will also be built.
 
 The documentation for the rust components are found at [rustc doc].
 
-[rustc doc]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/
+[rustc doc]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/
diff --git a/src/closure.md b/src/closure.md
index deeed0722..d4f9fc385 100644
--- a/src/closure.md
+++ b/src/closure.md
@@ -115,9 +115,9 @@ Let's start with defining a term that we will be using quite a bit in the rest o
 *upvar*. An **upvar** is a variable that is local to the function where the closure is defined. So,
 in the above examples, **x** will be an upvar to the closure. They are also sometimes referred to as
 the *free variables* meaning they are not bound to the context of the closure.
-[`src/librustc/ty/query/mod.rs`][upvars] defines a query called *upvars* for this purpose.
+[`src/librustc_middle/ty/query/mod.rs`][upvars] defines a query called *upvars* for this purpose.
 
-[upvars]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/query/queries/struct.upvars.html
+[upvars]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/query/queries/struct.upvars.html
 
 Other than lazy invocation, one other thing that the distinguishes a closure from a
 normal function is that it can use the upvars. It borrows these upvars from its surrounding
@@ -135,10 +135,10 @@ and `FnOnce` for move semantics.
 
 Most of the code related to the closure is in the
 [`src/librustc_typeck/check/upvar.rs`][upvar] file and the data structures are
-declared in the file [`src/librustc/ty/mod.rs`][ty].
+declared in the file [`src/librustc_middle/ty/mod.rs`][ty].
 
 [upvar]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_typeck/check/upvar/index.html
-[ty]:https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/index.html
+[ty]:https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/index.html
 
 Before we go any further, let's discuss how we can examine the flow of control through the rustc
 codebase. For closures specifically, set the `RUST_LOG` env variable as below and collect the
@@ -183,9 +183,9 @@ The callbacks are defined by implementing the [`Delegate`] trait. The
 records for each upvar which mode of borrow was required. The modes of borrow
 can be `ByValue` (moved) or `ByRef` (borrowed). For `ByRef` borrows, it can be
 `shared`, `shallow`, `unique` or `mut` as defined in the
-[`src/librustc/mir/mod.rs`][mir_mod].
+[`src/librustc_middle/mir/mod.rs`][mir_mod].
 
-[mir_mod]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/index.html
+[mir_mod]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/index.html
 
 `Delegate` defines a few different methods (the different callbacks):
 **consume**: for *move* of a variable, **borrow** for a *borrow* of some kind
@@ -193,7 +193,7 @@ can be `ByValue` (moved) or `ByRef` (borrowed). For `ByRef` borrows, it can be
 
 All of these callbacks have a common argument *cmt* which stands for Category,
 Mutability and Type and is defined in
-[`src/librustc/middle/mem_categorization.rs`][cmt]. Borrowing from the code
+[`src/librustc_middle/middle/mem_categorization.rs`][cmt]. Borrowing from the code
 comments, "`cmt` is a complete categorization of a value indicating where it
 originated and how it is located, as well as the mutability of the memory in
 which the value is stored". Based on the callback (consume, borrow etc.), we
diff --git a/src/compiler-debugging.md b/src/compiler-debugging.md
index 08e9417b3..9358e0c15 100644
--- a/src/compiler-debugging.md
+++ b/src/compiler-debugging.md
@@ -130,11 +130,11 @@ stack backtrace:
   (~~~ IRRELEVANT PART OF BACKTRACE REMOVED BY ME ~~~)
    7: rustc::traits::error_reporting::<impl rustc::infer::InferCtxt<'a, 'tcx>>
              ::report_selection_error
-             at /home/user/rust/src/librustc/traits/error_reporting.rs:823
+             at /home/user/rust/src/librustc_middle/traits/error_reporting.rs:823
    8: rustc::traits::error_reporting::<impl rustc::infer::InferCtxt<'a, 'tcx>>
              ::report_fulfillment_errors
-             at /home/user/rust/src/librustc/traits/error_reporting.rs:160
-             at /home/user/rust/src/librustc/traits/error_reporting.rs:112
+             at /home/user/rust/src/librustc_middle/traits/error_reporting.rs:160
+             at /home/user/rust/src/librustc_middle/traits/error_reporting.rs:112
    9: rustc_typeck::check::FnCtxt::select_obligations_where_possible
              at /home/user/rust/src/librustc_typeck/check/mod.rs:2192
   (~~~ IRRELEVANT PART OF BACKTRACE REMOVED BY ME ~~~)
@@ -172,11 +172,11 @@ look at the log output with a text editor.
 So to put it together.
 
 ```bash
-# This puts the output of all debug calls in `librustc/traits` into
+# This puts the output of all debug calls in `librustc_middle/traits` into
 # standard error, which might fill your console backscroll.
 $ RUSTC_LOG=rustc::traits rustc +local my-file.rs
 
-# This puts the output of all debug calls in `librustc/traits` in
+# This puts the output of all debug calls in `librustc_middle/traits` in
 # `traits-log`, so you can then see it with a text editor.
 $ RUSTC_LOG=rustc::traits rustc +local my-file.rs 2>traits-log
 
diff --git a/src/compiler-team.md b/src/compiler-team.md
index 42f6cc0ac..3f3719f3d 100644
--- a/src/compiler-team.md
+++ b/src/compiler-team.md
@@ -36,8 +36,7 @@ They are held on [Zulip][zulip]. It works roughly as follows:
 - **Look over new regressions:** we then look for new cases where the
   compiler broke previously working code in the wild. Regressions are
   almost always marked as P-high; the major exception would be bug
-  fixes (though even there we often
-  [aim to give warnings first][procedure]).
+  fixes (though even there we often [aim to give warnings first][procedure]).
 - **Check I-nominated issues:** These are issues where feedback from
   the team is desired.
 - **Check for beta nominations:** These are nominations of things to
@@ -52,7 +51,7 @@ complicated).
 The meeting is held over a "chat medium", currently on [zulip].
 
 [etherpad]: https://public.etherpad-mozilla.org/p/rust-compiler-meeting
-[procedure]: https://forge.rust-lang.org/rustc-bug-fix-procedure.html
+[procedure]: ./bug-fix-procedure.md
 [zulip]: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler
 
 ## Team membership
diff --git a/src/diagnostics.md b/src/diagnostics.md
index c112f3471..4810e4fa6 100644
--- a/src/diagnostics.md
+++ b/src/diagnostics.md
@@ -162,7 +162,7 @@ The possible values of [`Applicability`][appl] are:
 The compiler linting infrastructure is defined in the [`rustc::lint`][rlint]
 module.
 
-[rlint]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/lint/index.html
+[rlint]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/lint/index.html
 
 ### Declaring a lint
 
@@ -324,7 +324,7 @@ like normal but invokes the lint with `buffer_lint`.
 
 The parser (`librustc_ast`) is interesting in that it cannot have dependencies on
 any of the other `librustc*` crates. In particular, it cannot depend on
-`librustc::lint` or `librustc_lint`, where all of the compiler linting
+`librustc_middle::lint` or `librustc_lint`, where all of the compiler linting
 infrastructure is defined. That's troublesome!
 
 To solve this, `librustc_ast` defines its own buffered lint type, which
diff --git a/src/generics.md b/src/generics.md
index 310b9cda6..cdbf63b93 100644
--- a/src/generics.md
+++ b/src/generics.md
@@ -15,9 +15,9 @@ generic type parameters of the ADT.
 indicating what kind of generic the type parameter is (type, lifetime, or const).  Thus, `SubstsRef`
 is conceptually like a `&'tcx [GenericArgKind<'tcx>]` slice (but it is actually a `List`).
 
-[list]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.List.html
-[`GenericArg`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/subst/struct.GenericArg.html
-[`GenericArgKind`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/subst/enum.GenericArgKind.html
+[list]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.List.html
+[`GenericArg`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/subst/struct.GenericArg.html
+[`GenericArgKind`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/subst/enum.GenericArgKind.html
 
 So why do we use this `List` type instead of making it really a slice? It has the length "inline",
 so `&List` is only 32 bits. As a consequence, it cannot be "subsliced" (that only works if the
@@ -41,7 +41,7 @@ struct MyStruct<T>
 - This is one `TyKind::Adt` containing the `AdtDef` of `MyStruct` with the `SubstsRef` above.
 
 Finally, we will quickly mention the
-[`Generics`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.Generics.html) type. It
+[`Generics`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.Generics.html) type. It
 is used to give information about the type parameters of a type.
 
 ### Unsubstituted Generics
@@ -125,7 +125,7 @@ You may have a couple of followup questions…
  `MyStruct`: `Adt(Foo, &[Param(0), Param(1)])`.
 
 **`subst`** How do we actually do the substitutions? There is a function for that too! You use
-[`subst`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/subst/trait.Subst.html) to
+[`subst`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/subst/trait.Subst.html) to
 replace a `SubstRef` with another list of types.
 
 [Here is an example of actually using `subst` in the compiler][substex].  The exact details are not
diff --git a/src/high-level-overview.md b/src/high-level-overview.md
index 276ff8bc1..472d1ea03 100644
--- a/src/high-level-overview.md
+++ b/src/high-level-overview.md
@@ -100,7 +100,7 @@ take:
 3. **Lowering to HIR**
     - Once name resolution completes, we convert the AST into the HIR,
       or "[high-level intermediate representation]". The HIR is defined in
-      `src/librustc/hir/`; that module also includes the [lowering] code.
+      `src/librustc_middle/hir/`; that module also includes the [lowering] code.
     - The HIR is a lightly desugared variant of the AST. It is more processed
       than the AST and more suitable for the analyses that follow.
       It is **not** required to match the syntax of the Rust language.
diff --git a/src/hir.md b/src/hir.md
index 2c3e44a72..8b6637ebe 100644
--- a/src/hir.md
+++ b/src/hir.md
@@ -116,10 +116,10 @@ the [`hir::map`] module). The [HIR map] contains a [number of methods] to
 convert between IDs of various kinds and to lookup data associated
 with an HIR node.
 
-[`tcx.hir_map`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/context/struct.GlobalCtxt.html#structfield.hir_map
-[`hir::map`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/map/index.html
-[HIR map]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/map/struct.Map.html
-[number of methods]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/map/struct.Map.html#methods
+[`tcx.hir_map`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.GlobalCtxt.html#structfield.hir_map
+[`hir::map`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/hir/map/index.html
+[HIR map]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/hir/map/struct.Map.html
+[number of methods]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/hir/map/struct.Map.html#methods
 
 For example, if you have a [`DefId`], and you would like to convert it
 to a [`NodeId`], you can use
@@ -129,7 +129,7 @@ something outside of the current crate (since then it has no HIR
 node), but otherwise returns `Some(n)` where `n` is the node-id of the
 definition.
 
-[as_local_node_id]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/map/struct.Map.html#method.as_local_node_id
+[as_local_node_id]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/hir/map/struct.Map.html#method.as_local_node_id
 
 Similarly, you can use [`tcx.hir.find(n)`][find] to lookup the node for a
 [`NodeId`]. This returns a `Option<Node<'tcx>>`, where [`Node`] is an enum
@@ -140,15 +140,15 @@ that `n` must be some HIR expression, you can do
 [`tcx.hir.expect_expr(n)`][expect_expr], which will extract and return the
 [`&hir::Expr`][Expr], panicking if `n` is not in fact an expression.
 
-[find]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/map/struct.Map.html#method.find
+[find]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/hir/map/struct.Map.html#method.find
 [`Node`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/enum.Node.html
-[expect_expr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/map/struct.Map.html#method.expect_expr
+[expect_expr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/hir/map/struct.Map.html#method.expect_expr
 [Expr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/struct.Expr.html
 
 Finally, you can use the HIR map to find the parents of nodes, via
 calls like [`tcx.hir.get_parent_node(n)`][get_parent_node].
 
-[get_parent_node]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/map/struct.Map.html#method.get_parent_node
+[get_parent_node]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/hir/map/struct.Map.html#method.get_parent_node
 
 ### HIR Bodies
 
@@ -161,5 +161,5 @@ associated with a given def-id ([`maybe_body_owned_by`]) or to find
 the owner of a body ([`body_owner_def_id`]).
 
 [`rustc_hir::Body`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/struct.Body.html
-[`maybe_body_owned_by`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/map/struct.Map.html#method.maybe_body_owned_by
-[`body_owner_def_id`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/map/struct.Map.html#method.body_owner_def_id
+[`maybe_body_owned_by`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/hir/map/struct.Map.html#method.maybe_body_owned_by
+[`body_owner_def_id`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/hir/map/struct.Map.html#method.body_owner_def_id
diff --git a/src/lowering.md b/src/lowering.md
index c3a1a96cc..e0dc99bab 100644
--- a/src/lowering.md
+++ b/src/lowering.md
@@ -18,7 +18,7 @@ of such structures include but are not limited to
     * Converted to a virtual `existential type` declaration
 
 Lowering needs to uphold several invariants in order to not trigger the
-sanity checks in `src/librustc/hir/map/hir_id_validator.rs`:
+sanity checks in `src/librustc_middle/hir/map/hir_id_validator.rs`:
 
 1. A `HirId` must be used if created. So if you use the `lower_node_id`,
   you *must* use the resulting `NodeId` or `HirId` (either is fine, since
diff --git a/src/macro-expansion.md b/src/macro-expansion.md
index db58733ad..279598270 100644
--- a/src/macro-expansion.md
+++ b/src/macro-expansion.md
@@ -383,7 +383,7 @@ implementation of macro_rules, turns macro_rules DSL into something with
 signature Fn(TokenStream) -> TokenStream that can eat and produce tokens,
 @mark-i-m knows more about this librustc_resolve/macros.rs - resolving macro
 paths, validating those resolutions, reporting various "not found"/"found, but
-it's unstable"/"expected x, found y" errors librustc/hir/map/def_collector.rs +
+it's unstable"/"expected x, found y" errors librustc_middle/hir/map/def_collector.rs +
 librustc_resolve/build_reduced_graph.rs - integrate an AST fragment freshly
 expanded from a macro into various parent/child structures like module
 hierarchy or "definition paths"
diff --git a/src/memory.md b/src/memory.md
index bfec4fe19..620b7d858 100644
--- a/src/memory.md
+++ b/src/memory.md
@@ -16,8 +16,8 @@ types for equality: for each interned type `X`, we implemented [`PartialEq for
 X`][peqimpl], so we can just compare pointers. The [`CtxtInterners`] type
 contains a bunch of maps of interned types and the arena itself.
 
-[peqimpl]: https://github.com/rust-lang/rust/blob/3ee936378662bd2e74be951d6a7011a95a6bd84d/src/librustc/ty/mod.rs#L528-L534
-[`CtxtInterners`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.CtxtInterners.html#structfield.arena
+[peqimpl]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TyS.html#implementations
+[`CtxtInterners`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.CtxtInterners.html#structfield.arena
 
 ### Example: `ty::TyS`
 
@@ -49,10 +49,10 @@ allocate, and which are found in this module. Here are a few examples:
 - [`Predicate`] defines something the trait system has to prove (see `traits` module).
 
 [subst]: ./generic_arguments.html#subst
-[`TraitRef`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.TraitRef.html
-[`Predicate`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.Predicate.html
+[`TraitRef`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TraitRef.html
+[`Predicate`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.Predicate.html
 
-[`ty::TyS`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.TyS.html
+[`ty::TyS`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TyS.html
 
 ## The tcx and how it uses lifetimes
 
@@ -85,4 +85,4 @@ duplication while also preventing a lot of the ergonomic issues due to many
 pervasive lifetimes. The [`rustc::ty::tls`][tls] module is used to access these
 thread-locals, although you should rarely need to touch it.
 
-[tls]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/tls/index.html
+[tls]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/tls/index.html
diff --git a/src/mir/index.md b/src/mir/index.md
index dbc2a316f..99396903c 100644
--- a/src/mir/index.md
+++ b/src/mir/index.md
@@ -15,7 +15,7 @@ graphs and desugaring), you may enjoy the
 
 ## Introduction to MIR
 
-MIR is defined in the [`src/librustc/mir/`][mir] module, but much of the code
+MIR is defined in the [`src/librustc_middle/mir/`][mir] module, but much of the code
 that manipulates it is found in [`src/librustc_mir`][mirmanip].
 
 [RFC 1211]: https://rust-lang.github.io/rfcs/1211-mir.html
@@ -212,7 +212,7 @@ over the overflow checks.)
 
 ## MIR data types
 
-The MIR data types are defined in the [`src/librustc/mir/`][mir]
+The MIR data types are defined in the [`src/librustc_middle/mir/`][mir]
 module.  Each of the key concepts mentioned in the previous section
 maps in a fairly straightforward way to a Rust type.
 
@@ -253,7 +253,7 @@ but [you can read about those below](#promoted)).
 *to be written*
 
 
-[mir]: https://github.com/rust-lang/rust/tree/master/src/librustc/mir
+[mir]: https://github.com/rust-lang/rust/tree/master/src/librustc_middle/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
+[mir]: https://github.com/rust-lang/rust/tree/master/src/librustc_middle/mir
 [newtype'd]: ../appendix/glossary.html
diff --git a/src/mir/visitor.md b/src/mir/visitor.md
index a5e8e9a0b..a0d38ca0b 100644
--- a/src/mir/visitor.md
+++ b/src/mir/visitor.md
@@ -7,7 +7,7 @@ them, generated via a single macro: `Visitor` (which operates on a
 `&Mir` and gives back shared references) and `MutVisitor` (which
 operates on a `&mut Mir` and gives back mutable references).
 
-[m-v]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/visit/index.html
+[m-v]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/visit/index.html
 
 To implement a visitor, you have to create a type that represents
 your visitor. Typically, this type wants to "hang on" to whatever
@@ -50,6 +50,6 @@ contains useful functions for walking the MIR CFG in
 [different standard orders][traversal] (e.g. pre-order, reverse
 post-order, and so forth).
 
-[t]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/traversal/index.html
+[t]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/traversal/index.html
 [traversal]: https://en.wikipedia.org/wiki/Tree_traversal
 
diff --git a/src/miri.md b/src/miri.md
index 1f11633a7..16f2a18f2 100644
--- a/src/miri.md
+++ b/src/miri.md
@@ -95,14 +95,14 @@ Miri, but just use the cached result.
 
 [`Operand`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/interpret/enum.Operand.html
 [`Immediate`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/interpret/enum.Immediate.html
-[`ConstValue`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/interpret/enum.ConstValue.html
-[`Scalar`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/interpret/enum.Scalar.html
+[`ConstValue`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/interpret/enum.ConstValue.html
+[`Scalar`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/interpret/enum.Scalar.html
 [`op_to_const`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/const_eval/eval_queries/fn.op_to_const.html
 
 ## Datastructures
 
 Miri's outside-facing datastructures can be found in
-[librustc/mir/interpret](https://github.com/rust-lang/rust/blob/master/src/librustc/mir/interpret).
+[librustc_middle/mir/interpret](https://github.com/rust-lang/rust/blob/master/src/librustc_middle/mir/interpret).
 This is mainly the error enum and the [`ConstValue`] and [`Scalar`] types. A
 `ConstValue` can be either `Scalar` (a single `Scalar`, i.e., integer or thin
 pointer), `Slice` (to represent byte slices and strings, as needed for pattern
@@ -177,9 +177,9 @@ needed to support circular statics, where we need to have a `Pointer` to a
 bytes of its value.
 
 [`Memory`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/interpret/struct.Memory.html
-[`Allocation`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/interpret/struct.Allocation.html
-[`Pointer`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/interpret/struct.Pointer.html
-[`GlobalAlloc`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/interpret/enum.GlobalAlloc.html
+[`Allocation`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/interpret/struct.Allocation.html
+[`Pointer`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/interpret/struct.Pointer.html
+[`GlobalAlloc`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/interpret/enum.GlobalAlloc.html
 
 ### Pointer values vs Pointer types
 
diff --git a/src/panic-implementation.md b/src/panic-implementation.md
index 497c81fd0..549a9cd05 100644
--- a/src/panic-implementation.md
+++ b/src/panic-implementation.md
@@ -24,7 +24,7 @@ unsafe { panic_impl(&pi) }
 
 Actually resolving this goes through several layers of indirection:
 
-1. In `src/librustc/middle/weak_lang_items.rs`, `panic_impl` is declared as 'weak lang item',
+1. In `src/librustc_middle/middle/weak_lang_items.rs`, `panic_impl` is declared as 'weak lang item',
    with the symbol `rust_begin_unwind`. This is used in `librustc_typeck/collect.rs`
    to set the actual symbol name to `rust_begin_unwind`.
 
@@ -44,7 +44,7 @@ pub fn begin_panic_handler(info: &PanicInfo<'_>) -> ! {
 }
 ```
 
-The special `panic_handler` attribute is resolved via `src/librustc/middle/lang_items`.
+The special `panic_handler` attribute is resolved via `src/librustc_middle/middle/lang_items`.
 The `extract` function converts the `panic_handler` attribute to a `panic_impl` lang item.
 
 Now, we have a matching `panic_handler` lang item in the `libstd`. This function goes
diff --git a/src/param_env.md b/src/param_env.md
index 9ca117b31..aa6d6e215 100644
--- a/src/param_env.md
+++ b/src/param_env.md
@@ -8,7 +8,7 @@ type's `Layout`, but you can do all kinds of other checks on it (e.g. whether a
 type implements `Copy`) or you can evaluate an associated constant whose value
 does not depend on anything from the parameter environment.
 
-[pe]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.ParamEnv.html
+[pe]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.ParamEnv.html
 
 For example if you have a function
 
@@ -65,5 +65,5 @@ method. This will produce a [`ParamEnvAnd<Ty>`][pea], making clear that you
 should probably not be using the inner value without taking care to also use
 the [`ParamEnv`][pe].
 
-[and]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.ParamEnv.html#method.and
-[pea]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.ParamEnvAnd.html
+[and]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.ParamEnv.html#method.and
+[pea]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.ParamEnvAnd.html
diff --git a/src/queries/incremental-compilation-in-detail.md b/src/queries/incremental-compilation-in-detail.md
index 505dde1a8..a41becfd0 100644
--- a/src/queries/incremental-compilation-in-detail.md
+++ b/src/queries/incremental-compilation-in-detail.md
@@ -175,7 +175,7 @@ fn try_mark_green(tcx, current_node) -> bool {
 }
 
 // Note: The actual implementation can be found in
-//       src/librustc/dep_graph/graph.rs
+//       src/librustc_middle/dep_graph/graph.rs
 ```
 
 By using red-green marking we can avoid the devastating cumulative effect of
diff --git a/src/queries/incremental-compilation.md b/src/queries/incremental-compilation.md
index bed21f115..be8580f2d 100644
--- a/src/queries/incremental-compilation.md
+++ b/src/queries/incremental-compilation.md
@@ -81,7 +81,7 @@ Try-mark-green works as follows:
 ### The query DAG
 
 The query DAG code is stored in
-[`src/librustc/dep_graph`][dep_graph]. Construction of the DAG is done
+[`src/librustc_middle/dep_graph`][dep_graph]. Construction of the DAG is done
 by instrumenting the query execution.
 
 One key point is that the query DAG also tracks ordering; that is, for
@@ -113,7 +113,7 @@ of order, however, it might visit `subquery2` before `subquery1`, and hence
 execute it.
 This can lead to ICEs and other problems in the compiler.
 
-[dep_graph]: https://github.com/rust-lang/rust/tree/master/src/librustc/dep_graph
+[dep_graph]: https://github.com/rust-lang/rust/tree/master/src/librustc_middle/dep_graph
 
 ## Improvements to the basic algorithm
 
diff --git a/src/queries/profiling.md b/src/queries/profiling.md
index 156fd65a9..37b1bc97b 100644
--- a/src/queries/profiling.md
+++ b/src/queries/profiling.md
@@ -259,7 +259,7 @@ We give some background about the query model of the Rust compiler.
 In the query model, many queries have a key that consists of a Def ID. The Rust
 compiler uses Def IDs to distinguish definitions in the input Rust program.
 
-From the compiler source code (`src/librustc/hir/def_id.rs`):
+From the compiler source code (`src/librustc_middle/hir/def_id.rs`):
 
 ```
 /// A DefId identifies a particular *definition*, by combining a crate
diff --git a/src/query.md b/src/query.md
index 9ae6baa9e..e008cb628 100644
--- a/src/query.md
+++ b/src/query.md
@@ -99,7 +99,7 @@ When the tcx is created, it is given the providers by its creator using
 the [`Providers`][providers_struct] struct. This struct is generated by
 the macros here, but it is basically a big list of function pointers:
 
-[providers_struct]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/query/struct.Providers.html
+[providers_struct]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/query/struct.Providers.html
 
 ```rust,ignore
 struct Providers {
@@ -118,7 +118,7 @@ throughout the other `rustc_*` crates. This is done by invoking
 various [`provide`][provide_fn] functions. These functions tend to look
 something like this:
 
-[provide_fn]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/fn.provide.html
+[provide_fn]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/hir/fn.provide.html
 
 ```rust,ignore
 pub fn provide(providers: &mut Providers) {
@@ -172,9 +172,9 @@ Well, defining a query takes place in two steps:
 
 To specify the query name and arguments, you simply add an entry to
 the big macro invocation in
-[`src/librustc/query/mod.rs`][query-mod], which looks something like:
+[`src/librustc_middle/query/mod.rs`][query-mod], which looks something like:
 
-[query-mod]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/query/index.html
+[query-mod]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/query/index.html
 
 ```rust,ignore
 rustc_queries! {
@@ -225,7 +225,7 @@ Let's go over them one by one:
 - **Query modifiers:** various flags and options that customize how the
   query is processed.
 
-[Key]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/query/keys/trait.Key.html
+[Key]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/query/keys/trait.Key.html
 
 So, to add a query:
 
@@ -263,8 +263,8 @@ Implementing this trait is optional if the query key is `DefId`, but
 if you *don't* implement it, you get a pretty generic error ("processing `foo`...").
 You can put new impls into the `config` module. They look something like this:
 
-[QueryConfig]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/query/trait.QueryConfig.html
-[QueryDescription]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/query/config/trait.QueryDescription.html
+[QueryConfig]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/query/trait.QueryConfig.html
+[QueryDescription]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_query_system/query/config/trait.QueryDescription.html
 
 ```rust,ignore
 impl<'tcx> QueryDescription for queries::type_of<'tcx> {
diff --git a/src/rustc-driver.md b/src/rustc-driver.md
index 90a88b3d6..6a2e87f4d 100644
--- a/src/rustc-driver.md
+++ b/src/rustc-driver.md
@@ -42,7 +42,7 @@ replaces this functionality.
 [`rustc_driver`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver/
 [`Compiler`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/interface/struct.Compiler.html
 [`Session`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/struct.Session.html
-[`TyCtxt`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.TyCtxt.html
+[`TyCtxt`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TyCtxt.html
 [`SourceMap`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/source_map/struct.SourceMap.html
 [stupid-stats]: https://github.com/nrc/stupid-stats
 [Appendix A]: appendix/stupid-stats.html
diff --git a/src/tests/intro.md b/src/tests/intro.md
index b70a23a6a..b47a9fdee 100644
--- a/src/tests/intro.md
+++ b/src/tests/intro.md
@@ -129,7 +129,7 @@ Rust's [platform tiers]).
 [Azure Pipelines]: https://dev.azure.com/rust-lang/rust/
 [bors]: https://github.com/servo/homu
 [queue]: https://buildbot2.rust-lang.org/homu/queue/rust
-[platform tiers]: https://forge.rust-lang.org/platform-support.html
+[platform tiers]: https://forge.rust-lang.org/release/platform-support.html#rust-platform-support
 
 ## Testing with Docker images
 
diff --git a/src/traits/associated-types.md b/src/traits/associated-types.md
index d35fb71e1..41ce5ac9e 100644
--- a/src/traits/associated-types.md
+++ b/src/traits/associated-types.md
@@ -94,12 +94,12 @@ They are used internally by the trait system only, as we will see
 shortly.
 
 In rustc, they correspond to the `TyKind::UnnormalizedProjectionTy` enum
-variant, declared in [`librustc/ty/sty.rs`][sty]. In chalk, we use an
+variant, declared in [`librustc_middle/ty/sty.rs`][sty]. In chalk, we use an
 `ApplicationTy` with a name living in a special namespace dedicated to
 placeholder associated types (see the `TypeName` enum declared in
 [`chalk-ir/src/lib.rs`][chalk_type_name]).
 
-[sty]: https://github.com/rust-lang/rust/blob/master/src/librustc/ty/sty.rs
+[sty]: https://github.com/rust-lang/rust/blob/master/src/librustc_middle/ty/sty.rs
 [chalk_type_name]: https://github.com/rust-lang-nursery/chalk/blob/master/chalk-ir/src/lib.rs
 
 ## Projection equality
diff --git a/src/traits/goals-and-clauses.md b/src/traits/goals-and-clauses.md
index a653528f4..5aba1c20f 100644
--- a/src/traits/goals-and-clauses.md
+++ b/src/traits/goals-and-clauses.md
@@ -38,11 +38,11 @@ paper
 gives the details.
 
 In terms of code, these types are defined in
-[`librustc/traits/mod.rs`][traits_mod] in rustc, and in
+[`librustc_middle/traits/mod.rs`][traits_mod] in rustc, and in
 [`chalk-ir/src/lib.rs`][chalk_ir] in chalk.
 
 [pphhf]: ./bibliography.html#pphhf
-[traits_mod]: https://github.com/rust-lang/rust/blob/master/src/librustc/traits/mod.rs
+[traits_mod]: https://github.com/rust-lang/rust/blob/master/src/librustc_middle/traits/mod.rs
 [chalk_ir]: https://github.com/rust-lang-nursery/chalk/blob/master/chalk-ir/src/lib.rs
 
 <a name="domain-goals"></a>
diff --git a/src/ty-fold.md b/src/ty-fold.md
index e144767dc..5b409e8ec 100644
--- a/src/ty-fold.md
+++ b/src/ty-fold.md
@@ -6,9 +6,9 @@ on a type like we did with `Vec` above. But we might also have a more complex ty
 nested inside that also need substitutions.
 
 The answer is a couple of traits:
-[`TypeFoldable`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/fold/trait.TypeFoldable.html)
+[`TypeFoldable`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/fold/trait.TypeFoldable.html)
 and
-[`TypeFolder`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/fold/trait.TypeFolder.html).
+[`TypeFolder`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/fold/trait.TypeFolder.html).
 
 - `TypeFoldable` is implemented by types that embed type information. It allows you to recursively
   process the contents of the `TypeFoldable` and do stuff to them.
@@ -16,7 +16,7 @@ and
   `TypeFoldable`.
 
 For example, the `TypeFolder` trait has a method
-[`fold_ty`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/fold/trait.TypeFolder.html#method.fold_ty)
+[`fold_ty`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/fold/trait.TypeFolder.html#method.fold_ty)
 that takes a type as input a type and returns a new type as a result. `TypeFoldable` invokes the
 `TypeFolder` `fold_foo` methods on itself, giving the `TypeFolder` access to its contents (the
 types, regions, etc that are contained within).
@@ -35,7 +35,7 @@ So to reiterate:
 - `TypeFoldable`  is a trait that is implemented by things that embed types.
 
 In the case of `subst`, we can see that it is implemented as a `TypeFolder`:
-[`SubstFolder`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/subst/struct.SubstFolder.html).
+[`SubstFolder`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/subst/struct.SubstFolder.html).
 Looking at its implementation, we see where the actual substitutions are happening.
 
 However, you might also notice that the implementation calls this `super_fold_with` method. What is
@@ -93,13 +93,13 @@ defined
 [here](https://github.com/rust-lang/rust/blob/master/src/librustc_macros/src/type_foldable.rs).
 
 **`subst`** In the case of substitutions the [actual
-folder](https://github.com/rust-lang/rust/blob/04e69e4f4234beb4f12cc76dcc53e2cc4247a9be/src/librustc/ty/subst.rs#L467-L482)
+folder](https://github.com/rust-lang/rust/blob/75ff3110ac6d8a0259023b83fd20d7ab295f8dd6/src/librustc_middle/ty/subst.rs#L440-L451)
 is going to be doing the indexing we’ve already mentioned. There we define a `Folder` and call
 `fold_with` on the `TypeFoldable` to process yourself.  Then
-[fold_ty](https://github.com/rust-lang/rust/blob/04e69e4f4234beb4f12cc76dcc53e2cc4247a9be/src/librustc/ty/subst.rs#L545-L573)
+[fold_ty](https://github.com/rust-lang/rust/blob/75ff3110ac6d8a0259023b83fd20d7ab295f8dd6/src/librustc_middle/ty/subst.rs#L512-L536)
 the method that process each type it looks for a `ty::Param` and for those it replaces it for
 something from the list of substitutions, otherwise recursively process the type.  To replace it,
 calls
-[ty_for_param](https://github.com/rust-lang/rust/blob/04e69e4f4234beb4f12cc76dcc53e2cc4247a9be/src/librustc/ty/subst.rs#L589-L624)
+[ty_for_param](https://github.com/rust-lang/rust/blob/75ff3110ac6d8a0259023b83fd20d7ab295f8dd6/src/librustc_middle/ty/subst.rs#L552-L587)
 and all that does is index into the list of substitutions with the index of the `Param`.
 
diff --git a/src/ty.md b/src/ty.md
index a4274bc9f..f8b15632b 100644
--- a/src/ty.md
+++ b/src/ty.md
@@ -12,13 +12,13 @@ The `ty` module defines how the Rust compiler represents types internally. It al
 When we talk about how rustc represents types,  we usually refer to a type called `Ty` . There are
 quite a few modules and types for `Ty` in the compiler ([Ty documentation][ty]).
 
-[ty]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/index.html
+[ty]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/index.html
 
 The specific `Ty` we are referring to is [`rustc::ty::Ty`][ty_ty] (and not
 [`rustc_hir::Ty`][hir_ty]). The distinction is important, so we will discuss it first before going
 into the details of `ty::Ty`.
 
-[ty_ty]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/type.Ty.html
+[ty_ty]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/type.Ty.html
 [hir_ty]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/struct.Ty.html
 
 ## `rustc_hir::Ty` vs `ty::Ty`
@@ -124,9 +124,9 @@ are [interned](./memory.md), so that the `ty::Ty` can be a thin pointer-like
 type. This allows us to do cheap comparisons for equality, along with the other
 benefits of interning.
 
-[tys]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.TyS.html
-[kind]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.TyS.html#structfield.kind
-[tykind]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.TyKind.html
+[tys]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TyS.html
+[kind]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TyS.html#structfield.kind
+[tykind]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.TyKind.html
 
 ## Allocating and working with types
 
@@ -150,7 +150,7 @@ allocate exactly the same type twice).
 You can also find various common types in the `tcx` itself by accessing `tcx.types.bool`,
 `tcx.types.char`, etc (see [`CommonTypes`] for more).
 
-[`CommonTypes`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/context/struct.CommonTypes.html
+[`CommonTypes`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.CommonTypes.html
 
 ## `ty::TyKind` Variants
 
@@ -207,16 +207,16 @@ will discuss this more later.
 [**And Many More**...][kindvars]
 
 [wikiadt]: https://en.wikipedia.org/wiki/Algebraic_data_type
-[kindadt]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.TyKind.html#variant.Adt
-[kindforeign]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.TyKind.html#variant.Foreign
-[kindstr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.TyKind.html#variant.Str
-[kindslice]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.TyKind.html#variant.Slice
-[kindarray]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.TyKind.html#variant.Array
-[kindrawptr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.TyKind.html#variant.RawPtr
-[kindref]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.TyKind.html#variant.Ref
-[kindparam]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.TyKind.html#variant.Param
-[kinderr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.TyKind.html#variant.Error
-[kindvars]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.TyKind.html#variants
+[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
 
 ## Import conventions
 
@@ -259,8 +259,8 @@ There are two parts:
   generic parameters.  In our example of `MyStruct<u32>`, we would end up with a list like `[u32]`.
   We’ll dig more into generics and substitutions in a little bit.
 
-[adtdef]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.AdtDef.html
-[substsref]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/subst/type.SubstsRef.html
+[adtdef]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.AdtDef.html
+[substsref]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/subst/type.SubstsRef.html
 
 **`AdtDef` and `DefId`**
 
@@ -275,7 +275,7 @@ essentially a one-to-one relationship between `AdtDef` and `DefId`. You can get
 `DefId` with the [`tcx.adt_def(def_id)` query][adtdefq].  The `AdtDef`s are all interned (as you can
 see `'tcx` lifetime on it).
 
-[adtdefq]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.TyCtxt.html#method.adt_def
+[adtdefq]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TyCtxt.html#method.adt_def
 
 
 ## Type errors