diff --git a/src/appendix/code-index.md b/src/appendix/code-index.md
index 8561efe4c..68d12be37 100644
--- a/src/appendix/code-index.md
+++ b/src/appendix/code-index.md
@@ -6,30 +6,30 @@ compiler.
 
 Item            |  Kind    | Short description           | Chapter            | Declaration
 ----------------|----------|-----------------------------|--------------------|-------------------
-`BodyId` | struct | One of four types of HIR node identifiers | [Identifiers in the HIR] | [src/librustc_hir/hir.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/struct.BodyId.html)
-`Compiler` | struct | Represents a compiler session and can be used to drive a compilation. | [The Rustc Driver and Interface] | [src/librustc_interface/interface.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/interface/struct.Compiler.html)
-`ast::Crate` | struct | A syntax-level representation of a parsed crate | [The parser] | [src/librustc_ast/ast.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/ast/struct.Crate.html)
-`rustc_hir::Crate` | struct | A more abstract, compiler-friendly form of a crate's AST | [The Hir] | [src/librustc_hir/hir.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/struct.Crate.html)
-`DefId` | struct | One of four types of HIR node identifiers | [Identifiers in the HIR] | [src/librustc_hir/def_id.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/def_id/struct.DefId.html)
-`DiagnosticBuilder` | struct | A struct for building up compiler diagnostics, such as errors or lints | [Emitting Diagnostics] | [src/librustc_errors/diagnostic_builder.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.DiagnosticBuilder.html)
+`BodyId` | struct | One of four types of HIR node identifiers | [Identifiers in the HIR] | [compiler/rustc_hir/src/hir.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/struct.BodyId.html)
+`Compiler` | struct | Represents a compiler session and can be used to drive a compilation. | [The Rustc Driver and Interface] | [compiler/rustc_interface/src/interface.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/interface/struct.Compiler.html)
+`ast::Crate` | struct | A syntax-level representation of a parsed crate | [The parser] | [compiler/rustc_ast/src/ast.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/ast/struct.Crate.html)
+`rustc_hir::Crate` | struct | A more abstract, compiler-friendly form of a crate's AST | [The Hir] | [compiler/rustc_hir/src/hir.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/struct.Crate.html)
+`DefId` | struct | One of four types of HIR node identifiers | [Identifiers in the HIR] | [compiler/rustc_hir/src/def_id.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/def_id/struct.DefId.html)
+`DiagnosticBuilder` | struct | A struct for building up compiler diagnostics, such as errors or lints | [Emitting Diagnostics] | [compiler/rustc_errors/src/diagnostic_builder.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.DiagnosticBuilder.html)
 `DocContext` | struct | A state container used by rustdoc when crawling through a crate to gather its documentation | [Rustdoc] | [src/librustdoc/core.rs](https://github.com/rust-lang/rust/blob/master/src/librustdoc/core.rs)
-`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_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_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_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]  |  [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)
+`HirId` | struct | One of four types of HIR node identifiers | [Identifiers in the HIR] | [compiler/rustc_hir/src/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] | [compiler/rustc_ast/src/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 | [compiler/rustc_ast/src/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] | [compiler/rustc_middle/src/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] | [compiler/rustc_session/src/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] | [compiler/rustc_interface/src/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] | [compiler/rustc_resolve/src/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] | [compiler/rustc_session/src/session.rs](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] | [compiler/rustc_span/src/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] | [compiler/rustc_span/src/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] | [compiler/rustc_span/src/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] |  [compiler/rustc_parse/src/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] | [compiler/rustc_ast/src/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] |  [compiler/rustc_middle/src/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]  |  [compiler/rustc_middle/src/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] | [compiler/rustc_middle/src/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] | [compiler/rustc_middle/src/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 748f4feb5..007edce8d 100644
--- a/src/appendix/glossary.md
+++ b/src/appendix/glossary.md
@@ -16,7 +16,7 @@ cx <div id="cx"/>                        |  We tend to use "cx" as an abbreviati
 DAG <div id="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 <div id="data-flow"/> |  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).
 DeBruijn Index <div id="debruijn">       |  A technique for describing which binder a variable is bound by using only integers. It has the benefit that it is invariant under variable renaming. ([see more](./background.md#what-is-a-debruijn-index))
-DefId <div id="def-id"/>                 |  An index identifying a definition (see `librustc_middle/hir/def_id.rs`). Uniquely identifies a `DefPath`. See [the HIR chapter for more](../hir.html#identifiers-in-the-hir).
+DefId <div id="def-id"/>                 |  An index identifying a definition (see `rustc_middle/src/hir/def_id.rs`). Uniquely identifies a `DefPath`. See [the HIR chapter for more](../hir.html#identifiers-in-the-hir).
 Discriminant <div id="discriminant"/>    |  The underlying value associated with an enum variant or generator state to indicate it as "active" (but not to be confused with its ["variant index"](#variant-idx)). At runtime, the discriminant of the active variant is encoded in the [tag](#tag).
 Double pointer <div id="double-ptr"/>    |  A pointer with additional metadata. See "fat pointer" for more.
 drop glue <div id="drop-glue"/>          |  (internal) compiler-generated instructions that handle calling the destructors (`Drop`) for data types.
@@ -31,7 +31,7 @@ HirId <div id="hir-id"/>                 |  Identifies a particular node in the
 HIR Map <div id="hir-map"/>              |  The HIR map, accessible via tcx.hir, allows you to quickly navigate the HIR and convert between various forms of identifiers.
 ICE <div id="ice"/>                      |  Short for internal compiler error, this is when the compiler crashes.
 ICH <div id="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.
-infcx <div id="infcx"/>                  |  The inference context (see `librustc_middle/infer`)
+infcx <div id="infcx"/>                  |  The inference context (see `rustc_middle/src/infer`)
 inference variable <div id="inf-var"/>   |  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.
 intern <div id="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.
 intrinsic <div id="intrinsic"/>          |  Intrinsics are special functions that are implemented in the compiler itself but exposed (often unstably) to users. They do magical and dangerous things. (See [`std::intrinsics`](https://doc.rust-lang.org/std/intrinsics/index.html))
diff --git a/src/backend/backend-agnostic.md b/src/backend/backend-agnostic.md
index 07914b847..e1eeb9a7f 100644
--- a/src/backend/backend-agnostic.md
+++ b/src/backend/backend-agnostic.md
@@ -1,7 +1,7 @@
 # Backend Agnostic Codegen
 
 In the future, it would be nice to allow other codegen backends (e.g.
-[Cranelift]). To this end, `librustc_codegen_ssa` provides an
+[Cranelift]). To this end, `rustc_codegen_ssa` provides an
 abstract interface for all backends to implement.
 
 [Cranelift]: https://github.com/bytecodealliance/wasmtime/tree/HEAD/cranelift
diff --git a/src/backend/codegen.md b/src/backend/codegen.md
index 5db9b2b05..8e18ca242 100644
--- a/src/backend/codegen.md
+++ b/src/backend/codegen.md
@@ -63,8 +63,8 @@ before objects are passed on to the linker and some to happen during the
 linking.
 
 This all happens towards the very end of compilation. The code for this can be
-found in [`librustc_codegen_ssa::back`][ssaback] and
-[`librustc_codegen_llvm::back`][llvmback]. Sadly, this piece of code is not
+found in [`rustc_codegen_ssa::back`][ssaback] and
+[`rustc_codegen_llvm::back`][llvmback]. Sadly, this piece of code is not
 really well-separated into LLVM-dependent code; the [`rustc_codegen_ssa`][ssa]
 contains a fair amount of code specific to the LLVM backend.
 
diff --git a/src/backend/lowering-mir.md b/src/backend/lowering-mir.md
index 2ab15e6f8..8b9dbe7ce 100644
--- a/src/backend/lowering-mir.md
+++ b/src/backend/lowering-mir.md
@@ -15,14 +15,14 @@ MIR to LLVM IR.
 
 The code is split into modules which handle particular MIR primitives:
 
-- [`librustc_codegen_ssa::mir::block`][mirblk] will deal with translating
+- [`rustc_codegen_ssa::mir::block`][mirblk] will deal with translating
   blocks and their terminators.  The most complicated and also the most
   interesting thing this module does is generating code for function calls,
   including the necessary unwinding handling IR.
-- [`librustc_codegen_ssa::mir::statement`][mirst] translates MIR statements.
-- [`librustc_codegen_ssa::mir::operand`][mirop] translates MIR operands.
-- [`librustc_codegen_ssa::mir::place`][mirpl] translates MIR place references.
-- [`librustc_codegen_ssa::mir::rvalue`][mirrv] translates MIR r-values.
+- [`rustc_codegen_ssa::mir::statement`][mirst] translates MIR statements.
+- [`rustc_codegen_ssa::mir::operand`][mirop] translates MIR operands.
+- [`rustc_codegen_ssa::mir::place`][mirpl] translates MIR place references.
+- [`rustc_codegen_ssa::mir::rvalue`][mirrv] translates MIR r-values.
 
 [mirblk]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/mir/block/index.html
 [mirst]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/mir/statement/index.html
@@ -49,7 +49,7 @@ and can be found in [`rustc_codegen_llvm::intrinsic`][llvmint].
 [llvmint]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_llvm/intrinsic/index.html
 
 Everything else will use the [builder interface][builder]. This is the code that gets
-called in the [`librustc_codegen_ssa::mir::*`][ssamir] modules discussed above.
+called in the [`rustc_codegen_ssa::mir::*`][ssamir] modules discussed above.
 
 [builder]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_llvm/builder/index.html
 [ssamir]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/mir/index.html
diff --git a/src/borrow_check/region_inference.md b/src/borrow_check/region_inference.md
index 3b844b97c..d8cfab00c 100644
--- a/src/borrow_check/region_inference.md
+++ b/src/borrow_check/region_inference.md
@@ -82,7 +82,7 @@ maintain a set storing what elements are present in its value (to make this
 efficient, we give each kind of element an index, the `RegionElementIndex`, and
 use sparse bitsets).
 
-[ri]: https://github.com/rust-lang/rust/tree/master/src/librustc_mir/borrow_check/region_infer/
+[ri]: https://github.com/rust-lang/rust/tree/master/compiler/rustc_mir/src/borrow_check/region_infer/
 
 The kinds of region elements are as follows:
 
diff --git a/src/bug-fix-procedure.md b/src/bug-fix-procedure.md
index b4159097c..69732b627 100644
--- a/src/bug-fix-procedure.md
+++ b/src/bug-fix-procedure.md
@@ -65,7 +65,7 @@ described in more detail below):
 1. Once the change has been in the wild for at least one cycle, we can
    **stabilize the change**, converting those warnings into errors.
 
-Finally, for changes to `librustc_ast` that will affect plugins, the general policy
+Finally, for changes to `rustc_ast` that will affect plugins, the general policy
 is to batch these changes. That is discussed below in more detail.
 
 ### Tracking issue
@@ -120,7 +120,7 @@ future-compatibility warnings. These are a special category of lint warning.
 Adding a new future-compatibility warning can be done as follows.
 
 ```rust
-// 1. Define the lint in `src/librustc/lint/builtin.rs`:
+// 1. Define the lint in `compiler/rustc_middle/src/lint/builtin.rs`:
 declare_lint! {
     pub YOUR_ERROR_HERE,
     Warn,
@@ -137,7 +137,7 @@ impl LintPass for HardwiredLints {
     }
 }
 
-// 3. Register the lint in `src/librustc_lint/lib.rs`:
+// 3. Register the lint in `compiler/rustc_lint/src/lib.rs`:
 store.register_future_incompatible(sess, vec![
     ...,
     FutureIncompatibleInfo {
@@ -235,7 +235,7 @@ automatically generates the lower-case string; so searching for
 #### Remove the lint.
 
 The first reference you will likely find is the lint definition [in
-`librustc/lint/builtin.rs` that resembles this][defsource]:
+`rustc_session/src/lint/builtin.rs` that resembles this][defsource]:
 
 [defsource]: https://github.com/rust-lang/rust/blob/085d71c3efe453863739c1fb68fd9bd1beff214f/src/librustc/lint/builtin.rs#L171-L175
 
@@ -254,7 +254,7 @@ the file as [part of a `lint_array!`][lintarraysource]; remove it too,
 [lintarraysource]: https://github.com/rust-lang/rust/blob/085d71c3efe453863739c1fb68fd9bd1beff214f/src/librustc/lint/builtin.rs#L252-L290
 
 Next, you see see [a reference to `OVERLAPPING_INHERENT_IMPLS` in
-`librustc_lint/lib.rs`][futuresource]. This defining the lint as a "future
+`rustc_lint/src/lib.rs`][futuresource]. This defining the lint as a "future
 compatibility lint":
 
 ```rust
@@ -268,7 +268,7 @@ Remove this too.
 
 #### Add the lint to the list of removed lists.
 
-In `src/librustc_lint/lib.rs` there is a list of "renamed and removed lints".
+In `compiler/rustc_lint/src/lib.rs` there is a list of "renamed and removed lints".
 You can add this lint to the list:
 
 ```rust
diff --git a/src/building/bootstrapping.md b/src/building/bootstrapping.md
index a2eeb6029..d2384f9fc 100644
--- a/src/building/bootstrapping.md
+++ b/src/building/bootstrapping.md
@@ -259,7 +259,7 @@ thread 'main' panicked at 'RUSTC_STAGE was not set: NotPresent', library/core/sr
 
 If `./stageN/bin/rustc` gives an error about environment variables, that
 usually means something is quite wrong -- or you're trying to compile e.g.
-`librustc` or `std` or something that depends on environment variables. In
+`rustc` or `std` or something that depends on environment variables. In
 the unlikely case that you actually need to invoke rustc in such a situation,
 you can find the environment variable values by adding the following flag to
 your `x.py` command: `--on-fail=print-env`.
diff --git a/src/building/how-to-build-and-run.md b/src/building/how-to-build-and-run.md
index 29d10edd0..f2f87e1d6 100644
--- a/src/building/how-to-build-and-run.md
+++ b/src/building/how-to-build-and-run.md
@@ -183,7 +183,7 @@ This may *look* like it only builds `std`, but that is not the case.
 What this command does is the following:
 
 - Build `std` using the stage0 compiler (using incremental)
-- Build `librustc` using the stage0 compiler (using incremental)
+- Build `rustc` using the stage0 compiler (using incremental)
   - This produces the stage1 compiler
 - Build `std` using the stage1 compiler (cannot use incremental)
 
@@ -207,9 +207,9 @@ workflows"](./suggested.md) below.
 
 Note that this whole command just gives you a subset of the full `rustc`
 build. The **full** `rustc` build (what you get if you say `./x.py build
---stage 2 src/rustc`) has quite a few more steps:
+--stage 2 compiler/rustc`) has quite a few more steps:
 
-- Build `librustc` and `rustc` with the stage1 compiler.
+- Build `rustc` with the stage1 compiler.
   - The resulting compiler here is called the "stage2" compiler.
 - Build `std` with stage2 compiler.
 - Build `librustdoc` and a bunch of other things with the stage2 compiler.
diff --git a/src/building/new-target.md b/src/building/new-target.md
index eea01e9cc..24d47edad 100644
--- a/src/building/new-target.md
+++ b/src/building/new-target.md
@@ -48,7 +48,7 @@ somewhat successfully, you can copy the specification into the
 compiler itself.
 
 You will need to add a line to the big table inside of the
-`supported_targets` macro in the `librustc_target::spec` module. You
+`supported_targets` macro in the `rustc_target::spec` module. You
 will then add a corresponding file for your new target containing a
 `target` function.
 
@@ -94,7 +94,7 @@ cross-compile `rustc`:
 ```
 DESTDIR=/path/to/install/in \
 ./x.py install -i --stage 1 --host aarch64-apple-darwin.json --target aarch64-apple-darwin \
-src/librustc library/std
+compiler/rustc library/std
 ```
 
 If your target specification is already available in the bootstrap
diff --git a/src/closure.md b/src/closure.md
index 0f9b13965..3a7a10f5c 100644
--- a/src/closure.md
+++ b/src/closure.md
@@ -115,7 +115,7 @@ 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_middle/ty/query/mod.rs`][upvars] defines a query called *upvars_mentioned*
+[`compiler/rustc_middle/src/ty/query/mod.rs`][upvars] defines a query called *upv.rs_mentioned*
 for this purpose.
 
 [upvars]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/query/queries/struct.upvars_mentioned.html
@@ -135,8 +135,8 @@ appropriate trait: `Fn` trait for immutable borrow, `FnMut` for mutable borrow,
 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_middle/ty/mod.rs`][ty].
+[`compiler/rustc_typeck/src/check/upvar.rs`][upvar] file and the data structures are
+declared in the file [`compiler/rustc_middle/src/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_middle/ty/index.html
@@ -184,7 +184,7 @@ 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_middle/mir/mod.rs`][mir_mod].
+[`compiler/rustc_middle/src/mir/mod.rs`][mir_mod].
 
 [mir_mod]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/index.html
 
@@ -194,7 +194,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/middle/mem_categorization.rs`][cmt]. Borrowing from the code
+[`compiler/rustc_middle/src/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 0c40d63e4..ead9b020b 100644
--- a/src/compiler-debugging.md
+++ b/src/compiler-debugging.md
@@ -53,17 +53,17 @@ look like this:
 ```text
 stack backtrace:
    (~~~~ LINES REMOVED BY ME FOR BREVITY ~~~~)
-             at /home/user/rust/src/librustc_typeck/check/cast.rs:110
+             at /home/user/rust/compiler/rustc_typeck/src/check/cast.rs:110
    7: rustc_typeck::check::cast::CastCheck::check
-             at /home/user/rust/src/librustc_typeck/check/cast.rs:572
-             at /home/user/rust/src/librustc_typeck/check/cast.rs:460
-             at /home/user/rust/src/librustc_typeck/check/cast.rs:370
+             at /home/user/rust/compiler/rustc_typeck/src/check/cast.rs:572
+             at /home/user/rust/compiler/rustc_typeck/src/check/cast.rs:460
+             at /home/user/rust/compiler/rustc_typeck/src/check/cast.rs:370
    (~~~~ LINES REMOVED BY ME FOR BREVITY ~~~~)
   33: rustc_driver::driver::compile_input
-             at /home/user/rust/src/librustc_driver/driver.rs:1010
-             at /home/user/rust/src/librustc_driver/driver.rs:212
+             at /home/user/rust/compiler/rustc_driver/src/driver.rs:1010
+             at /home/user/rust/compiler/rustc_driver/src/driver.rs:212
   34: rustc_driver::run_compiler
-             at /home/user/rust/src/librustc_driver/lib.rs:253
+             at /home/user/rust/compiler/rustc_driver/src/lib.rs:253
 ```
 
 ## Getting a backtrace for errors
@@ -123,23 +123,23 @@ note: rustc 1.24.0-dev running on x86_64-unknown-linux-gnu
 note: run with `RUST_BACKTRACE=1` for a backtrace
 
 thread 'rustc' panicked at 'encountered error with `-Z treat_err_as_bug',
-/home/user/rust/src/librustc_errors/lib.rs:411:12
+/home/user/rust/compiler/rustc_errors/src/lib.rs:411:12
 note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose
 backtrace.
 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_middle/traits/error_reporting.rs:823
+             at /home/user/rust/compiler/rustc_middle/src/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_middle/traits/error_reporting.rs:160
-             at /home/user/rust/src/librustc_middle/traits/error_reporting.rs:112
+             at /home/user/rust/compiler/rustc_middle/src/traits/error_reporting.rs:160
+             at /home/user/rust/compiler/rustc_middle/src/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
+             at /home/user/rust/compiler/rustc_typeck/src/check/mod.rs:2192
   (~~~ IRRELEVANT PART OF BACKTRACE REMOVED BY ME ~~~)
   36: rustc_driver::run_compiler
-             at /home/user/rust/src/librustc_driver/lib.rs:253
+             at /home/user/rust/compiler/rustc_driver/src/lib.rs:253
 $ # Cool, now I have a backtrace for the error
 ```
 
@@ -174,11 +174,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_middle/traits` into
+# This puts the output of all debug calls in `rustc_middle/src/traits` into
 # standard error, which might fill your console backscroll.
 $ RUSTC_LOG=rustc_middle::traits rustc +local my-file.rs
 
-# This puts the output of all debug calls in `librustc_middle/traits` in
+# This puts the output of all debug calls in `rustc_middle/src/traits` in
 # `traits-log`, so you can then see it with a text editor.
 $ RUSTC_LOG=rustc_middle::traits rustc +local my-file.rs 2>traits-log
 
@@ -199,7 +199,7 @@ $ RUSTC_LOG=rustc_trans=info rustc +local my-file.rs
 # This will show the output of all `info!` calls made by rustdoc or any rustc library it calls.
 $ RUSTDOC_LOG=info rustdoc +local my-file.rs
 
-# This will only show `debug!` calls made by rustdoc directly, not any `librustc*` crate.
+# This will only show `debug!` calls made by rustdoc directly, not any `rustc*` crate.
 $ RUSTDOC_LOG=rustdoc rustdoc +local my-file.rs
 ```
 
diff --git a/src/compiler-src.md b/src/compiler-src.md
index df8bc2bd1..324b9105a 100644
--- a/src/compiler-src.md
+++ b/src/compiler-src.md
@@ -46,7 +46,7 @@ built in a special way because it can use unstable features.
 > NOTE: As of this writing, the crates all live in `src/`, but there is an MCP
 > to move them to a new `compiler/` directory.
 
-The compiler crates all have names starting with `librustc_*`. These are a
+The compiler crates all have names starting with `rustc_*`. These are a
 collection of around 50 interdependent crates ranging in size from tiny to
 huge. There is also the `rustc` crate which is the actual binary (i.e. the
 `main` function); it doesn't actually do anything besides calling the
diff --git a/src/diagnostics.md b/src/diagnostics.md
index 5ad2fbb32..a3293101f 100644
--- a/src/diagnostics.md
+++ b/src/diagnostics.md
@@ -71,11 +71,11 @@ Please read [RFC 1567] for details on how to format and write long error
 codes.
 
 The descriptions are written in markdown, and all of them are linked in the
-[`librustc_error_codes`] crate.
+[`rustc_error_codes`] crate.
 
 TODO: When should an error use an error code, and when shouldn't it?
 
-[`librustc_error_codes`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_error_codes/error_codes/index.html
+[`rustc_error_codes`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_error_codes/error_codes/index.html
 [error index]: https://doc.rust-lang.org/error-index.html
 [RFC 1567]: https://github.com/rust-lang/rfcs/blob/master/text/1567-long-error-codes-explanation-normalization.md
 
@@ -633,12 +633,12 @@ like normal but invokes the lint with `buffer_lint`.
 
 #### Linting even earlier in the compiler
 
-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_middle::lint` or `librustc_lint`, where all of the compiler linting
+The parser (`rustc_ast`) is interesting in that it cannot have dependencies on
+any of the other `rustc*` crates. In particular, it cannot depend on
+`rustc_middle::lint` or `rustc_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
+To solve this, `rustc_ast` defines its own buffered lint type, which
 `ParseSess::buffer_lint` uses. After macro expansion, these buffered lints are
 then dumped into the `Session::buffered_lints` used by the rest of the compiler.
 
@@ -669,8 +669,8 @@ the structured JSON and see the "human" output (well, _sans_ colors)
 without having to compile everything twice.
 
 The "human" readable and the json format emitter can be found under
-librustc_errors, both were moved from the `librustc_ast` crate to the
-[librustc_errors crate](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/index.html).
+`rustc_errors`, both were moved from the `rustc_ast` crate to the
+[rustc_errors crate](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/index.html).
 
 The JSON emitter defines [its own `Diagnostic`
 struct](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/json/struct.Diagnostic.html)
diff --git a/src/diagnostics/diagnostic-codes.md b/src/diagnostics/diagnostic-codes.md
index e0d144bfc..d5aae201a 100644
--- a/src/diagnostics/diagnostic-codes.md
+++ b/src/diagnostics/diagnostic-codes.md
@@ -32,7 +32,7 @@ Here we see the highest error code in use is `E0591`, so we _probably_ want
 `E0592`. To be sure, run `rg E0592` and check, you should see no references.
 
 Next, open `src/{crate}/diagnostics.rs` within the crate where you wish to issue
-the error (e.g., `src/librustc_typeck/diagnostics.rs`). Ideally, you will add
+the error (e.g., `compiler/rustc_typeck/src/diagnostics.rs`). Ideally, you will add
 the code (in its proper numerical order) into the `register_long_diagnostics!`
 macro, sort of like this:
 
diff --git a/src/diagnostics/lintstore.md b/src/diagnostics/lintstore.md
index 2942dac02..8f0c21ab3 100644
--- a/src/diagnostics/lintstore.md
+++ b/src/diagnostics/lintstore.md
@@ -92,7 +92,7 @@ understanding the code. However, with the current type-erased lint store
 approach, it is beneficial to do so for performance reasons.
 
 New lints being added likely want to join one of the existing declarations like
-`late_lint_mod_passes` in `librustc_lint/lib.rs`, which would then
+`late_lint_mod_passes` in `rustc_lint/src/lib.rs`, which would then
 auto-propagate into the other.
 
 [`LintStore::register_lint`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/struct.LintStore.html#method.register_lints
diff --git a/src/implementing_new_features.md b/src/implementing_new_features.md
index 233d223db..2103c8803 100644
--- a/src/implementing_new_features.md
+++ b/src/implementing_new_features.md
@@ -126,7 +126,7 @@ a new unstable feature:
 2. Pick a name for the feature gate (for RFCs, use the name
    in the RFC).
 
-3. Add a feature gate declaration to `librustc_feature/active.rs`
+3. Add a feature gate declaration to `rustc_feature/src/active.rs`
    in the active `declare_features` block:
 
    ```rust,ignore
diff --git a/src/lowering.md b/src/lowering.md
index e0dc99bab..a4d270b4d 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_middle/hir/map/hir_id_validator.rs`:
+sanity checks in `compiler/rustc_middle/src/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 1b06cab41..7f704d05d 100644
--- a/src/macro-expansion.md
+++ b/src/macro-expansion.md
@@ -1,6 +1,6 @@
 # Macro expansion
 
-> `librustc_ast`, `librustc_expand`, and `librustc_builtin_macros` are all undergoing
+> `rustc_ast`, `rustc_expand`, and `rustc_builtin_macros` are all undergoing
 > refactoring, so some of the links in this chapter may be broken.
 
 Rust has a very powerful macro system. In the previous chapter, we saw how the
@@ -222,7 +222,7 @@ a macro author may want to introduce a new name to the context where the macro
 was called. Alternately, the macro author may be defining a variable for use
 only within the macro (i.e. it should not be visible outside the macro).
 
-[code_dir]: https://github.com/rust-lang/rust/tree/master/src/librustc_expand/mbe
+[code_dir]: https://github.com/rust-lang/rust/tree/master/compiler/rustc_expand/src/mbe
 [code_mp]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/mbe/macro_parser
 [code_mr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/mbe/macro_rules
 [code_parse_int]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/mbe/macro_parser/fn.parse_tt.html
@@ -232,7 +232,7 @@ The context is attached to AST nodes. All AST nodes generated by macros have
 context attached. Additionally, there may be other nodes that have context
 attached, such as some desugared syntax (non-macro-expanded nodes are
 considered to just have the "root" context, as described below).
-Throughout the compiler, we use [`librustc_span::Span`s][span] to refer to code locations.
+Throughout the compiler, we use [`rustc_span::Span`s][span] to refer to code locations.
 This struct also has hygiene information attached to it, as we will see later.
 
 [span]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/struct.Span.html
@@ -442,7 +442,7 @@ are expanded, we may invoke the MBE parser to parse and expand a macro.  The
 MBE parser, in turn, may call the normal Rust parser when it needs to bind a
 metavariable (e.g.  `$my_expr`) while parsing the contents of a macro
 invocation. The code for macro expansion is in
-[`src/librustc_expand/mbe/`][code_dir].
+[`compiler/rustc_expand/src/mbe/`][code_dir].
 
 ### Example
 
@@ -495,7 +495,7 @@ invocations. Interestingly, both are done by the macro parser.
 Basically, the MBE parser is like an NFA-based regex parser. It uses an
 algorithm similar in spirit to the [Earley parsing
 algorithm](https://en.wikipedia.org/wiki/Earley_parser). The macro parser is
-defined in [`src/librustc_expand/mbe/macro_parser.rs`][code_mp].
+defined in [`compiler/rustc_expand/src/mbe/macro_parser.rs`][code_mp].
 
 The interface of the macro parser is as follows (this is slightly simplified):
 
@@ -542,7 +542,7 @@ normal Rust parser.
 As mentioned above, both definitions and invocations of macros are parsed using
 the macro parser. This is extremely non-intuitive and self-referential. The code
 to parse macro _definitions_ is in
-[`src/librustc_expand/mbe/macro_rules.rs`][code_mr]. It defines the pattern for
+[`compiler/rustc_expand/src/mbe/macro_rules.rs`][code_mr]. It defines the pattern for
 matching for a macro definition as `$( $lhs:tt => $rhs:tt );+`. In other words,
 a `macro_rules` definition should have in its body at least one occurrence of a
 token tree followed by `=>` followed by another token tree. When the compiler
@@ -571,7 +571,7 @@ the parse is ambiguous, while if there are no matches at all, there is a syntax
 error.
 
 For more information about the macro parser's implementation, see the comments
-in [`src/librustc_expand/mbe/macro_parser.rs`][code_mp].
+in [`compiler/rustc_expand/src/mbe/macro_parser.rs`][code_mp].
 
 ### `macro`s and Macros 2.0
 
diff --git a/src/mir/index.md b/src/mir/index.md
index 85c5d755e..f771fa0ed 100644
--- a/src/mir/index.md
+++ b/src/mir/index.md
@@ -15,8 +15,8 @@ graphs and desugaring), you may enjoy the
 
 ## Introduction to MIR
 
-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].
+MIR is defined in the [`compiler/rustc_middle/src/mir/`][mir] module, but much of the code
+that manipulates it is found in [`compiler/rustc_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_middle/mir/`][mir]
+The MIR data types are defined in the [`compiler/rustc_middle/src/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,6 @@ but [you can read about those below](#promoted)).
 *to be written*
 
 
-[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_middle/mir
+[mir]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/index.html
+[mirmanip]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/index.html
 [newtype'd]: ../appendix/glossary.html#newtype
diff --git a/src/miri.md b/src/miri.md
index 76996271d..af2a92802 100644
--- a/src/miri.md
+++ b/src/miri.md
@@ -102,7 +102,7 @@ Miri, but just use the cached result.
 ## Datastructures
 
 Miri's outside-facing datastructures can be found in
-[librustc_middle/mir/interpret](https://github.com/rust-lang/rust/blob/master/src/librustc_middle/mir/interpret).
+[rustc_middle/src/mir/interpret](https://github.com/rust-lang/rust/blob/master/compiler/rustc_middle/src/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
@@ -202,7 +202,7 @@ division on pointer values.
 
 Although the main entry point to constant evaluation is the `tcx.const_eval_*`
 functions, there are additional functions in
-[librustc_mir/const_eval.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/const_eval/index.html)
+[rustc_mir/src/const_eval.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/const_eval/index.html)
 that allow accessing the fields of a `ConstValue` (`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).
@@ -213,7 +213,7 @@ function with no arguments, except that constants do not allow local (named)
 variables at the time of writing this guide.
 
 A stack frame is defined by the `Frame` type in
-[librustc_mir/interpret/eval_context.rs](https://github.com/rust-lang/rust/blob/master/src/librustc_mir/interpret/eval_context.rs)
+[rustc_mir/src/interpret/eval_context.rs](https://github.com/rust-lang/rust/blob/master/compiler/rustc_mir/src/interpret/eval_context.rs)
 and contains all the local
 variables memory (`None` at the start of evaluation). Each frame refers to the
 evaluation of either the root constant or subsequent calls to `const fn`. The
@@ -225,7 +225,7 @@ The frames are just a `Vec<Frame>`, there's no way to actually refer to a
 memory that can be referred to are `Allocation`s.
 
 Miri now calls the `step` method (in
-[librustc_mir/interpret/step.rs](https://github.com/rust-lang/rust/blob/master/src/librustc_mir/interpret/step.rs)
+[rustc_mir/src/interpret/step.rs](https://github.com/rust-lang/rust/blob/master/compiler/rustc_mir/src/interpret/step.rs)
 ) until it either returns an error or has no further statements to execute. Each
 statement will now initialize or modify the locals or the virtual memory
 referred to by a local. This might require evaluating other constants or
diff --git a/src/name-resolution.md b/src/name-resolution.md
index cc6eed7f8..ebd44da1d 100644
--- a/src/name-resolution.md
+++ b/src/name-resolution.md
@@ -55,7 +55,7 @@ A successful run of the second phase ([`Resolver::resolve_crate`]) creates kind
 of an index the rest of the compilation may use to ask about the present names
 (through the `hir::lowering::Resolver` interface).
 
-The name resolution lives in the `librustc_resolve` crate, with the meat in
+The name resolution lives in the `rustc_resolve` crate, with the meat in
 `lib.rs` and some helpers or symbol-type specific logic in the other modules.
 
 [`Resolver::resolve_crate`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_resolve/struct.Resolver.html#method.resolve_crate
diff --git a/src/overview.md b/src/overview.md
index 5bcf26911..baa1e0aa6 100644
--- a/src/overview.md
+++ b/src/overview.md
@@ -22,31 +22,31 @@ we'll talk about that later.
   enable nightly features (`-Z` flags), perform `check`-only builds, or emit
   LLVM-IR rather than executable machine code. The `rustc` executable call may
   be indirect through the use of `cargo`.
-- Command line argument parsing occurs in the [`librustc_driver`]. This crate
+- Command line argument parsing occurs in the [`rustc_driver`]. This crate
   defines the compile configuration that is requested by the user and passes it
   to the rest of the compilation process as a [`rustc_interface::Config`].
 - The raw Rust source text is analyzed by a low-level lexer located in
-  [`librustc_lexer`]. At this stage, the source text is turned into a stream of
+  [`rustc_lexer`]. At this stage, the source text is turned into a stream of
   atomic source code units known as _tokens_.  The lexer supports the
   Unicode character encoding.
 - The token stream passes through a higher-level lexer located in
-  [`librustc_parse`] to prepare for the next stage of the compile process. The
+  [`rustc_parse`] to prepare for the next stage of the compile process. The
   [`StringReader`] struct is used at this stage to perform a set of validations
   and turn strings into interned symbols (_interning_ is discussed later).
 - The lexer has a small interface and doesn't depend directly on the
   diagnostic infrastructure in `rustc`. Instead it provides diagnostics as plain
-  data which are emitted in `librustc_parse::lexer::mod` as real diagnostics.
+  data which are emitted in `rustc_parse::lexer::mod` as real diagnostics.
 - The lexer preserves full fidelity information for both IDEs and proc macros.
 - The parser [translates the token stream from the lexer into an Abstract Syntax
   Tree (AST)][parser]. It uses a recursive descent (top-down) approach to syntax
   analysis. The crate entry points for the parser are the `Parser::parse_crate_mod()` and
-  `Parser::parse_mod()` methods found in `librustc_parse::parser::item`. The external
-  module parsing entry point is `librustc_expand::module::parse_external_mod`. And
+  `Parser::parse_mod()` methods found in `rustc_parse::parser::item`. The external
+  module parsing entry point is `rustc_expand::module::parse_external_mod`. And
   the macro parser entry point is [`Parser::parse_nonterminal()`][parse_nonterminal].
 - Parsing is performed with a set of `Parser` utility methods including `fn bump`,
   `fn check`, `fn eat`, `fn expect`, `fn look_ahead`.
 - Parsing is organized by the semantic construct that is being parsed. Separate
-  `parse_*` methods can be found in `librustc_parse` `parser` directory. The source
+  `parse_*` methods can be found in `rustc_parse` `parser` directory. The source
   file name follows the construct name. For example, the following files are found
   in the parser:
     - `expr.rs`
@@ -97,12 +97,12 @@ we'll talk about that later.
   - The different libraries/binaries are linked together to produce the final
     binary.
 
-[`librustc_lexer`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lexer/index.html
-[`librustc_driver`]: https://rustc-dev-guide.rust-lang.org/rustc-driver.html
+[`rustc_lexer`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lexer/index.html
+[`rustc_driver`]: https://rustc-dev-guide.rust-lang.org/rustc-driver.html
 [`rustc_interface::Config`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/interface/struct.Config.html
 [lex]: https://rustc-dev-guide.rust-lang.org/the-parser.html
 [`StringReader`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/lexer/struct.StringReader.html
-[`librustc_parse`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/index.html
+[`rustc_parse`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/index.html
 [parser]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/index.html
 [hir]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/index.html
 [type inference]: https://rustc-dev-guide.rust-lang.org/type-inference.html
@@ -340,16 +340,16 @@ For more details on bootstrapping, see
   - Main entry point: [`rustc_session::config::build_session_options`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/config/fn.build_session_options.html)
 - Lexical Analysis: Lex the user program to a stream of tokens
   - Guide: [Lexing and Parsing](https://rustc-dev-guide.rust-lang.org/the-parser.html)
-  - Lexer definition: [`librustc_lexer`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lexer/index.html)
+  - Lexer definition: [`rustc_lexer`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lexer/index.html)
   - Main entry point: [`rustc_lexer::first_token`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lexer/fn.first_token.html)
 - Parsing: Parse the stream of tokens to an Abstract Syntax Tree (AST)
   - Guide: [Lexing and Parsing](https://rustc-dev-guide.rust-lang.org/the-parser.html)
-  - Parser definition: [`librustc_parse`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/index.html)
+  - Parser definition: [`rustc_parse`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/index.html)
   - Main entry points:
     - [Entry point for first file in crate](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/passes/fn.parse.html)
     - [Entry point for outline module parsing](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/module/fn.parse_external_mod.html)
     - [Entry point for macro fragments][parse_nonterminal]
-  - AST definition: [`librustc_ast`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/ast/index.html)
+  - AST definition: [`rustc_ast`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/ast/index.html)
   - Expansion: **TODO**
   - Name Resolution: **TODO**
   - Feature gating: **TODO**
@@ -371,8 +371,8 @@ For more details on bootstrapping, see
     - These two functions can't be decoupled.
 - The Mid Level Intermediate Representation (MIR)
   - Guide: [The MIR (Mid level IR)](https://rustc-dev-guide.rust-lang.org/mir/index.html)
-  - Definition: [`librustc_middle/mir`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/index.html)
-  - Definition of source that manipulates the MIR: [`librustc_mir`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/index.html)
+  - Definition: [`rustc_middle/src/mir`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/index.html)
+  - Definition of source that manipulates the MIR: [`rustc_mir`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/index.html)
 - The Borrow Checker
   - Guide: [MIR Borrow Check](https://rustc-dev-guide.rust-lang.org/borrow_check.html)
   - Definition: [`rustc_mir/borrow_check`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/index.html)
diff --git a/src/panic-implementation.md b/src/panic-implementation.md
index 1b4f827d4..7c10ae215 100644
--- a/src/panic-implementation.md
+++ b/src/panic-implementation.md
@@ -24,9 +24,10 @@ unsafe { panic_impl(&pi) }
 
 Actually resolving this goes through several layers of indirection:
 
-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`.
+1. In `compiler/rustc_middle/src/middle/weak_lang_items.rs`, `panic_impl` is
+   declared as 'weak lang item', with the symbol `rust_begin_unwind`. This is
+   used in `rustc_typeck/src/collect.rs` to set the actual symbol name to
+   `rust_begin_unwind`.
 
    Note that `panic_impl` is declared in an `extern "Rust"` block,
    which means that core will attempt to call a foreign symbol called `rust_begin_unwind`
@@ -44,7 +45,7 @@ pub fn begin_panic_handler(info: &PanicInfo<'_>) -> ! {
 }
 ```
 
-The special `panic_handler` attribute is resolved via `src/librustc_middle/middle/lang_items`.
+The special `panic_handler` attribute is resolved via `compiler/rustc_middle/src/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 `std`. This function goes
diff --git a/src/queries/incremental-compilation-in-detail.md b/src/queries/incremental-compilation-in-detail.md
index 96255227f..bea9a886f 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_middle/dep_graph/graph.rs
+//       compiler/rustc_middle/src/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 c8e7d4d7c..5ff189f96 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_middle/dep_graph`][dep_graph]. Construction of the DAG is done
+[`compiler/rustc_middle/src/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_middle/dep_graph
+[dep_graph]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/dep_graph/index.html
 
 ## Improvements to the basic algorithm
 
diff --git a/src/queries/profiling.md b/src/queries/profiling.md
index 593d0b385..ad31c9e53 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_middle/hir/def_id.rs`):
+From the compiler source code (`compiler/rustc_middle/src/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 be84fec54..52786ad34 100644
--- a/src/query.md
+++ b/src/query.md
@@ -114,7 +114,7 @@ for external crates, though the plan is that we may eventually have
 one per crate.
 
 These `Providers` structs are ultimately created and populated by
-`librustc_driver`, but it does this by distributing the work
+`rustc_driver`, but it does this by distributing the work
 throughout the other `rustc_*` crates. This is done by invoking
 various [`provide`][provide_fn] functions. These functions tend to look
 something like this:
@@ -159,7 +159,7 @@ they define both a [`provide`][ext_provide] and a
 [`provide_extern`][ext_provide_extern] function that `rustc_driver`
 can invoke.
 
-[rustc_metadata]: https://github.com/rust-lang/rust/tree/master/src/librustc_metadata
+[rustc_metadata]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_metadata/index.html
 [ext_provide]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_llvm/attributes/fn.provide.html
 [ext_provide_extern]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_llvm/attributes/fn.provide_extern.html
 
@@ -173,7 +173,7 @@ 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_middle/query/mod.rs`][query-mod], which looks something like:
+[`compiler/rustc_middle/src/query/mod.rs`][query-mod], which looks something like:
 
 [query-mod]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/query/index.html
 
diff --git a/src/stabilization_guide.md b/src/stabilization_guide.md
index 73875bceb..2cdb0037b 100644
--- a/src/stabilization_guide.md
+++ b/src/stabilization_guide.md
@@ -91,7 +91,7 @@ should appear in the documentation.
 ### Updating the feature-gate listing
 
 There is a central listing of feature-gates in
-[`src/librustc_feature`]. Search for the `declare_features!`
+[`compiler/rustc_feature`]. Search for the `declare_features!`
 macro. There should be an entry for the feature you are aiming
 to stabilize, something like (this example is taken from
 [rust-lang/rust#32409]:
@@ -140,7 +140,7 @@ Most importantly, remove the code which flags an error if the
 feature-gate is not present (since the feature is now considered
 stable). If the feature can be detected because it employs some
 new syntax, then a common place for that code to be is in the
-same `src/librustc_ast_passes/feature_gate.rs`.
+same `compiler/rustc_ast_passes/src/feature_gate.rs`.
 For example, you might see code like this:
 
 ```rust,ignore
@@ -175,7 +175,7 @@ if something { /* XXX */ }
 ```
 
 [rust-lang/rust#32409]: https://github.com/rust-lang/rust/issues/32409
-[`src/librustc_feature`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_feature/index.html
+[`compiler/rustc_feature`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_feature/index.html
 [The Reference]: https://github.com/rust-lang/reference
 [The Book]: https://github.com/rust-lang/book
 [Rust by Example]: https://github.com/rust-lang/rust-by-example
diff --git a/src/test-implementation.md b/src/test-implementation.md
index a5ddd9135..230e2fe36 100644
--- a/src/test-implementation.md
+++ b/src/test-implementation.md
@@ -32,14 +32,14 @@ How does any sort of `main` function invoke these tests if they're not visible?
 What exactly is `rustc --test` doing?
 
 `#[test]` is implemented as a syntactic transformation inside the compiler's
-[`librustc_ast` crate][librustc_ast]. Essentially, it's a fancy macro, that
+[`rustc_ast` crate][rustc_ast]. Essentially, it's a fancy macro, that
 rewrites the crate in 3 steps:
 
 #### Step 1: Re-Exporting
 
 As mentioned earlier, tests can exist inside private modules, so we need a
 way of exposing them to the main function, without breaking any existing
-code. To that end, `librustc_ast` will create local modules called
+code. To that end, `rustc_ast` will create local modules called
 `__test_reexports` that recursively reexport tests. This expansion translates
 the above example into:
 
@@ -79,7 +79,7 @@ hygiene.
 
 #### Step 2: Harness Generation
 Now that our tests are accessible from the root of our crate, we need to do
-something with them. `librustc_ast` generates a module like so:
+something with them. `rustc_ast` generates a module like so:
 
 ```rust,ignore
 #[main]
@@ -116,7 +116,7 @@ fn foo() {
 This means our tests are more than just simple functions, they have
 configuration information as well. `test` encodes this configuration data
 into a struct called [`TestDesc`][TestDesc]. For each test function in a
-crate, `librustc_ast` will parse its attributes and generate a `TestDesc`
+crate, `rustc_ast` will parse its attributes and generate a `TestDesc`
 instance. It then combines the `TestDesc` and test function into the
 predictably named `TestDescAndFn` struct, that `test_main_static` operates
 on. For a given test, the generated `TestDescAndFn` instance looks like so:
@@ -150,4 +150,4 @@ $ rustc my_mod.rs -Z unpretty=hir
 [Symbol]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/symbol/struct.Symbol.html
 [Ident]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/symbol/struct.Ident.html
 [eRFC]: https://github.com/rust-lang/rfcs/blob/master/text/2318-custom-test-frameworks.md
-[librustc_ast]: https://github.com/rust-lang/rust/tree/master/src/librustc_ast
+[rustc_ast]: https://github.com/rust-lang/rust/tree/master/compiler/rustc_ast
diff --git a/src/the-parser.md b/src/the-parser.md
index da318c9ef..7c59ddfe7 100644
--- a/src/the-parser.md
+++ b/src/the-parser.md
@@ -9,7 +9,7 @@ conveniently than strings. This happens in two stages: Lexing and Parsing.
 
 Lexing takes strings and turns them into streams of [tokens]. For example,
 `a.b + c` would be turned into the tokens `a`, `.`, `b`, `+`, and `c`.
-The lexer lives in [`librustc_lexer`][lexer].
+The lexer lives in [`rustc_lexer`][lexer].
 
 [tokens]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/token/index.html
 [lexer]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lexer/index.html
@@ -19,12 +19,12 @@ form which is easier for the compiler to work with, usually called an [*Abstract
 Syntax Tree*][ast] (AST). An AST mirrors the structure of a Rust program in memory,
 using a `Span` to link a particular AST node back to its source text.
 
-The AST is defined in [`librustc_ast`][librustc_ast], along with some definitions for
+The AST is defined in [`rustc_ast`][rustc_ast], along with some definitions for
 tokens and token streams, data structures/traits for mutating ASTs, and shared
 definitions for other AST-related parts of the compiler (like the lexer and
 macro-expansion).
 
-The parser is defined in [`librustc_parse`][librustc_parse], along with a
+The parser is defined in [`rustc_parse`][rustc_parse], along with a
 high-level interface to the lexer and some validation routines that run after
 macro expansion. In particular, the [`rustc_parse::parser`][parser] contains
 the parser implementation.
@@ -52,16 +52,16 @@ Code for lexical analysis is split between two crates:
   constituting tokens. Although it is popular to implement lexers as generated
   finite state machines, the lexer in `rustc_lexer` is hand-written.
 
-- [`StringReader`] from [`librustc_ast`][librustc_ast] integrates `rustc_lexer` with `rustc`
+- [`StringReader`] from [`rustc_ast`][rustc_ast] integrates `rustc_lexer` with `rustc`
   specific data structures. Specifically, it adds `Span` information to tokens
   returned by `rustc_lexer` and interns identifiers.
 
-[librustc_ast]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/index.html
+[rustc_ast]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/index.html
 [rustc_errors]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/index.html
 [ast]: https://en.wikipedia.org/wiki/Abstract_syntax_tree
 [`SourceMap`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/source_map/struct.SourceMap.html
 [ast module]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/ast/index.html
-[librustc_parse]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/index.html
+[rustc_parse]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/index.html
 [parser]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/parser/index.html
 [`Parser`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/parse/parser/struct.Parser.html
 [`StringReader`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/lexer/struct.StringReader.html
diff --git a/src/traits/chalk.md b/src/traits/chalk.md
index 70af2a1f5..659f69637 100644
--- a/src/traits/chalk.md
+++ b/src/traits/chalk.md
@@ -38,4 +38,4 @@ implementing them in rustc. We map our struct, trait, and impl declarations
 into logical inference rules in the [lowering module in rustc](./lowering-module.md).
 
 [chalk]: https://github.com/rust-lang/chalk
-[librustc_traits]: https://github.com/rust-lang/rust/tree/master/src/librustc_traits
+[rustc_traits]: https://github.com/rust-lang/rust/tree/master/compiler/rustc_traits
diff --git a/src/traits/goals-and-clauses.md b/src/traits/goals-and-clauses.md
index f4ceb99a0..9aaab96fa 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_middle/traits/mod.rs`][traits_mod] in rustc, and in
+[`rustc_middle/src/traits/mod.rs`][traits_mod] in rustc, and in
 [`chalk-ir/src/lib.rs`][chalk_ir] in chalk.
 
 [pphhf]: https://rust-lang.github.io/chalk/book/bibliography.html#pphhf
-[traits_mod]: https://github.com/rust-lang/rust/blob/master/src/librustc_middle/traits/mod.rs
+[traits_mod]: https://github.com/rust-lang/rust/blob/master/compiler/rustc_middle/src/traits/mod.rs
 [chalk_ir]: https://github.com/rust-lang/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 5b409e8ec..c390597f9 100644
--- a/src/ty-fold.md
+++ b/src/ty-fold.md
@@ -90,7 +90,7 @@ things. We only want to do something when we reach a type. That means there may
 implementations. Such implementations of `TypeFoldable` tend to be pretty tedious to write by hand.
 For this reason, there is a `derive` macro that allows you to `#![derive(TypeFoldable)]`. It is
 defined
-[here](https://github.com/rust-lang/rust/blob/master/src/librustc_macros/src/type_foldable.rs).
+[here](https://github.com/rust-lang/rust/blob/master/compiler/rustc_macros/src/type_foldable.rs).
 
 **`subst`** In the case of substitutions the [actual
 folder](https://github.com/rust-lang/rust/blob/75ff3110ac6d8a0259023b83fd20d7ab295f8dd6/src/librustc_middle/ty/subst.rs#L440-L451)
diff --git a/src/type-checking.md b/src/type-checking.md
index d4f4bf110..797cd9487 100644
--- a/src/type-checking.md
+++ b/src/type-checking.md
@@ -4,9 +4,9 @@ The [`rustc_typeck`][typeck] crate contains the source for "type collection"
 and "type checking", as well as a few other bits of related functionality. (It
 draws heavily on the [type inference] and [trait solving].)
 
-[typeck]: https://github.com/rust-lang/rust/tree/master/src/librustc_typeck
-[type inference]: type-inference.html
-[trait solving]: traits/resolution.html
+[typeck]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_typeck/index.html
+[type inference]: ./type-inference.md
+[trait solving]: ./traits/resolution.md
 
 ## Type collection
 
@@ -38,7 +38,7 @@ type *checking*).
 
 For more details, see the [`collect`][collect] module.
 
-[queries]: query.html
+[queries]: ./query.md
 [collect]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_typeck/collect/
 
 **TODO**: actually talk about type checking...