Change `rustc::*` to `rustc_middle::*` (#798)

src/diagnostics.md

@@ -459,7 +459,7 @@ The possible values of [`Applicability`][appl] are:
 
 ## Lints
 
-The compiler linting infrastructure is defined in the [`rustc::lint`][rlint]
+The compiler linting infrastructure is defined in the [`rustc_middle::lint`][rlint]
 module.
 
 [rlint]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/lint/index.html

src/diagnostics/lintstore.md

@@ -15,9 +15,9 @@ Unfortunately, a lot of the documentation we have refers to both of these as jus
 
 First, we have the lint declarations themselves: this is where the name and default lint level and
 other metadata come from. These are normally defined by way of the [`declare_lint!`] macro, which
-boils down to a static with type `&rustc::lint::Lint`. We lint against direct declarations without
-the use of the macro today (though this may change in the future, as the macro is somewhat unwieldy
-to add new fields to, like all macros by example).
+boils down to a static with type `&rustc_session::lint::Lint`. We lint against direct declarations
+without the use of the macro today (though this may change in the future, as the macro is somewhat
+unwieldy to add new fields to, like all macros by example).
 
 Lint declarations don't carry any "state" - they are merely global identifers and descriptions of
 lints. We assert at runtime that they are not registered twice (by lint name).
@@ -55,9 +55,9 @@ internally.
 Note, these include both rustc-internal lints, and the traditional lints, like, for example the dead
 code lint.
 
-These are primarily described in two places: `rustc::lint::builtin` and `rustc_lint::builtin`. The
-first provides the definitions for the lints themselves, and the latter provides the lint pass
-definitions (and implementations).
+These are primarily described in two places: `rustc_session::lint::builtin` and
+`rustc_lint::builtin`. The first provides the definitions for the lints themselves,
+and the latter provides the lint pass definitions (and implementations).
 
 The internal lint registration happens in the [`rustc_lint::register_builtins`] function, along with
 the [`rustc_lint::register_internals`] function. More generally, the LintStore "constructor"

src/memory.md

@@ -82,7 +82,7 @@ of the more Rust-ic "pull" style (think the `Iterator` trait).
 
 Thread-local storage and interning are used a lot through the compiler to reduce
 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
+pervasive lifetimes. The [`rustc_middle::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_middle/ty/tls/index.html

src/mir/visitor.md

@@ -2,7 +2,7 @@
 
 The MIR visitor is a convenient tool for traversing the MIR and either
 looking for things or making changes to it. The visitor traits are
-defined in [the `rustc::mir::visit` module][m-v] – there are two of
+defined in [the `rustc_middle::mir::visit` module][m-v] – there are two of
 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).
@@ -45,7 +45,7 @@ terminators and removes their `unwind` successors.
 
 ## Traversal
 
-In addition the visitor, [the `rustc::mir::traversal` module][t]
+In addition the visitor, [the `rustc_middle::mir::traversal` module][t]
 contains useful functions for walking the MIR CFG in
 [different standard orders][traversal] (e.g. pre-order, reverse
 post-order, and so forth).

src/overview.md

@@ -276,11 +276,11 @@ the name `'tcx`, which means that something is tied to the lifetime of the
 
 Types are really important in Rust, and they form the core of a lot of compiler
 analyses. The main type (in the compiler) that represents types (in the user's
-program) is [`rustc::ty::Ty`][ty]. This is so important that we have a whole chapter
+program) is [`rustc_middle::ty::Ty`][ty]. This is so important that we have a whole chapter
 on [`ty::Ty`][ty], but for now, we just want to mention that it exists and is the way
 `rustc` represents types!
 
-Also note that the `rustc::ty` module defines the `TyCtxt` struct we mentioned before.
+Also note that the `rustc_middle::ty` module defines the `TyCtxt` struct we mentioned before.
 
 [ty]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/type.Ty.html
 

src/ty.md

@@ -10,7 +10,7 @@ quite a few modules and types for `Ty` in the compiler ([Ty documentation][ty]).
 
 [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
+The specific `Ty` we are referring to is [`rustc_middle::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`.
 
@@ -107,7 +107,7 @@ or `fn(i32) -> i32` (with type aliases fully expanded).
 
 ## `ty::Ty` implementation
 
-[`rustc::ty::Ty`][ty_ty] is actually a type alias to [`&TyS`][tys].
+[`rustc_middle::ty::Ty`][ty_ty] is actually a type alias to [`&TyS`][tys].
 This type, which is short for "Type Structure", is where the main functionality is located.
 You can ignore `TyS` struct in general; you will basically never access it explicitly.
 We always pass it by reference using the `Ty` alias.