Fix links and paths

Author: JohnTitor

src/appendix/code-index.md

@@ -6,14 +6,14 @@ compiler.
 
 Item            |  Kind    | Short description           | Chapter            | Declaration
 ----------------|----------|-----------------------------|--------------------|-------------------
-`BodyId` | struct | One of four types of HIR node identifiers | [Identifiers in the HIR] | [src/librustc/hir/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/struct.BodyId.html)
+`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/hir/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ast/struct.Crate.html)
-`hir::Crate` | struct | A more abstract, compiler-friendly form of a crate's AST | [The Hir] | [src/librustc/hir/mod.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)
+`ast::Crate` | struct | A syntax-level representation of a parsed crate | [The parser] | [src/libsyntax/ast.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/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)
 `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/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/struct.HirId.html)
+`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/libsyntax/ast.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ast/struct.NodeId.html)
 `P` | struct | An owned immutable smart pointer. By contrast, `&T` is not owned, and `Box<T>` is not immutable. | None | [src/syntax/ptr.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/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)

src/hir.md

@@ -27,7 +27,7 @@ data structure basically just contains the root module, the HIR
 `Crate` structure contains a number of maps and other things that
 serve to organize the content of the crate for easier access.
 
-[`Crate`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/struct.Crate.html
+[`Crate`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/struct.Crate.html
 
 For example, the contents of individual items (e.g. modules,
 functions, traits, impls, etc) in the HIR are not immediately
@@ -45,7 +45,7 @@ struct) would only have the **`ItemId`** `I` of `bar()`. To get the
 details of the function `bar()`, we would lookup `I` in the
 `items` map.
 
-[`Mod`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/struct.Mod.html
+[`Mod`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/struct.Mod.html
 
 One nice result from this representation is that one can iterate
 over all items in the crate by iterating over the key-value pairs
@@ -55,14 +55,14 @@ as well as "bodies" (explained below).
 
 The other reason to set up the representation this way is for better
 integration with incremental compilation. This way, if you gain access
-to an [`&hir::Item`] (e.g. for the mod `foo`), you do not immediately
+to an [`&rustc_hir::Item`] (e.g. for the mod `foo`), you do not immediately
 gain access to the contents of the function `bar()`. Instead, you only
 gain access to the **id** for `bar()`, and you must invoke some
 function to lookup the contents of `bar()` given its id; this gives
 the compiler a chance to observe that you accessed the data for
 `bar()`, and then record the dependency.
 
-[`&hir::Item`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/struct.Item.html
+[`&rustc_hir::Item`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/struct.Item.html
 
 <a name="hir-id"></a>
 
@@ -97,9 +97,9 @@ sorts of identifiers in active use:
     tree causes the [`NodeId`]s of all subsequent code in the crate to change.
     This is terrible for incremental compilation, as you can perhaps imagine.
 
-[`DefId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/def_id/struct.DefId.html
-[`HirId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/struct.HirId.html
-[`BodyId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/struct.BodyId.html
+[`DefId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/def_id/struct.DefId.html
+[`HirId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/hir_id/struct.HirId.html
+[`BodyId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/struct.BodyId.html
 [`NodeId`]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ast/struct.NodeId.html
 
 We also have an internal map to go from `DefId` to what’s called "Def path". "Def path" is like a
@@ -141,9 +141,9 @@ that `n` must be some HIR expression, you can do
 [`&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
-[`Node`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/enum.Node.html
+[`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
-[Expr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/struct.Expr.html
+[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].
@@ -152,14 +152,14 @@ calls like [`tcx.hir.get_parent_node(n)`][get_parent_node].
 
 ### HIR Bodies
 
-A [`hir::Body`] represents some kind of executable code, such as the body
+A [`rustc_hir::Body`] represents some kind of executable code, such as the body
 of a function/closure or the definition of a constant. Bodies are
 associated with an **owner**, which is typically some kind of item
 (e.g. an `fn()` or `const`), but could also be a closure expression
 (e.g. `|x, y| x + y`). You can use the HIR map to find the body
 associated with a given def-id ([`maybe_body_owned_by`]) or to find
 the owner of a body ([`body_owner_def_id`]).
 
-[`hir::Body`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/struct.Body.html
+[`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

src/rustdoc.md

@@ -84,7 +84,7 @@ is the `impl Clean<Crate> for visit_ast::RustdocVisitor`, which is called by
 
 You see, I actually lied a little earlier: There's another AST transformation
 that happens before the events in `clean/mod.rs`.  In `visit_ast.rs` is the
-type `RustdocVisitor`, which *actually* crawls a `hir::Crate` to get the first
+type `RustdocVisitor`, which *actually* crawls a `rustc_hir::Crate` to get the first
 intermediate representation, defined in `doctree.rs`. This pass is mainly to
 get a few intermediate wrappers around the HIR types and to process visibility
 and inlining. This is where `#[doc(inline)]`, `#[doc(no_inline)]`, and

src/ty.md

@@ -15,13 +15,13 @@ 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
 
 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
+[`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
-[hir_ty]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/struct.Ty.html
+[hir_ty]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/struct.Ty.html
 
-## `hir::Ty` vs `ty::Ty`
+## `rustc_hir::Ty` vs `ty::Ty`
 
 The HIR in rustc can be thought of as the high-level intermediate representation. It is more or less
 the AST (see [this chapter](hir.md)) as it represents the
@@ -30,7 +30,7 @@ representation of types, but in reality it reflects more of what the user wrote,
 wrote so as to represent that type.
 
 In contrast, `ty::Ty` represents the semantics of a type, that is, the *meaning* of what the user
-wrote. For example, `hir::Ty` would record the fact that a user used the name `u32` twice in their
+wrote. For example, `rustc_hir::Ty` would record the fact that a user used the name `u32` twice in their
 program, but the `ty::Ty` would record the fact that both usages refer to the same type.
 
 **Example: `fn foo(x: u32) → u32 { }`** In this function we see that `u32` appears twice. We know
@@ -49,26 +49,26 @@ look like  `fn foo<'a>(x: &'a u32) -> &'a u32)`.
 In the HIR level, these things are not spelled out and you can say the picture is rather incomplete.
 However, at the `ty::Ty` level, these details are added and it is complete. Moreover, we will have
 exactly one `ty::Ty` for a given type, like `u32`, and that `ty::Ty` is used for all `u32`s in the
-whole program, not a specific usage, unlike `hir::Ty`.
+whole program, not a specific usage, unlike `rustc_hir::Ty`.
 
 Here is a summary:
 
-| [`hir::Ty`][hir_ty] | [`ty::Ty`][ty_ty] |
+| [`rustc_hir::Ty`][hir_ty] | [`ty::Ty`][ty_ty] |
 | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | Describe the *syntax* of a type: what the user wrote (with some desugaring).  | Describe the *semantics* of a type: the meaning of what the user wrote. |
-| Each `hir::Ty` has its own spans corresponding to the appropriate place in the program. | Doesn’t correspond to a single place in the user’s program. |
-| `hir::Ty` has generics and lifetimes; however, some of those lifetimes are special markers like [`LifetimeName::Implicit`][implicit]. | `ty::Ty` has the full type, including generics and lifetimes, even if the user left them out |
-| `fn foo(x: u32) → u32 { }` - Two `hir::Ty` representing each usage of `u32`. Each has its own `Span`s, etc.- `hir::Ty` doesn’t tell us that both are the same type | `fn foo(x: u32) → u32 { }` - One `ty::Ty` for all instances of `u32` throughout the program.- `ty::Ty` tells us that both usages of `u32` mean the same type. |
-| `fn foo(x: &u32) -> &u32)`- Two `hir::Ty` again.- Lifetimes for the references show up in the `hir::Ty`s using a special marker, [`LifetimeName::Implicit`][implicit]. | `fn foo(x: &u32) -> &u32)`- A single `ty::Ty`.- The `ty::Ty` has the hidden lifetime param |
+| Each `rustc_hir::Ty` has its own spans corresponding to the appropriate place in the program. | Doesn’t correspond to a single place in the user’s program. |
+| `rustc_hir::Ty` has generics and lifetimes; however, some of those lifetimes are special markers like [`LifetimeName::Implicit`][implicit]. | `ty::Ty` has the full type, including generics and lifetimes, even if the user left them out |
+| `fn foo(x: u32) → u32 { }` - Two `rustc_hir::Ty` representing each usage of `u32`. Each has its own `Span`s, etc.- `rustc_hir::Ty` doesn’t tell us that both are the same type | `fn foo(x: u32) → u32 { }` - One `ty::Ty` for all instances of `u32` throughout the program.- `ty::Ty` tells us that both usages of `u32` mean the same type. |
+| `fn foo(x: &u32) -> &u32)`- Two `rustc_hir::Ty` again.- Lifetimes for the references show up in the `rustc_hir::Ty`s using a special marker, [`LifetimeName::Implicit`][implicit]. | `fn foo(x: &u32) -> &u32)`- A single `ty::Ty`.- The `ty::Ty` has the hidden lifetime param |
 
-[implicit]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/enum.LifetimeName.html#variant.Implicit
+[implicit]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/enum.LifetimeName.html#variant.Implicit
 
 **Order** HIR is built directly from the AST, so it happens before any `ty::Ty` is produced. After
 HIR is built, some basic type inference and type checking is done. During the type inference, we
 figure out what the `ty::Ty` of everything is and we also check if the type of something is
 ambiguous. The `ty::Ty` then, is used for type checking while making sure everything has the
 expected type. The [`astconv` module][astconv], is where the code responsible for converting a
-`hir::Ty` into a `ty::Ty` is located. This occurs during the type-checking phase, but also in other
+`rustc_hir::Ty` into a `ty::Ty` is located. This occurs during the type-checking phase, but also in other
 parts of the compiler that want to ask questions like "what argument types does this function
 expect"?.
 
@@ -85,7 +85,7 @@ we determine that they semantically are the same type and that’s the `ty::Ty`
 
 Consider another example: `fn foo<T>(x: T) -> u32` and suppose that someone invokes `foo::<u32>(0)`.
 This means that `T` and `u32` (in this invocation) actually turns out to be the same type, so we
-would eventually end up with the same `ty::Ty` in the end, but we have distinct `hir::Ty`. (This is
+would eventually end up with the same `ty::Ty` in the end, but we have distinct `rustc_hir::Ty`. (This is
 a bit over-simplified, though, since during type checking, we would check the function generically
 and would still have a `T` distinct from `u32`. Later, when doing code generation, we would always
 be handling "monomorphized" (fully substituted) versions of each function, and hence we would know
@@ -104,7 +104,7 @@ mod b {
 }
 ```
 
-Here the type `X` will vary depending on context, clearly. If you look at the `hir::Ty`, you will
+Here the type `X` will vary depending on context, clearly. If you look at the `rustc_hir::Ty`, you will
 get back that `X` is an alias in both cases (though it will be mapped via name resolution to
 distinct aliases). But if you look at the `ty::Ty` signature, it will be either `fn(u32) -> u32` or
 `fn(i32) -> i32` (with type aliases fully expanded).
@@ -466,7 +466,7 @@ You may have a couple of followup questions…
 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
-too important, but in this piece of code, we happen to be converting from the `hir::Ty` to a real
+too important, but in this piece of code, we happen to be converting from the `rustc_hir::Ty` to a real
 `ty::Ty`. You can see that we first get some substitutions (`substs`).  Then we call `type_of` to
 get a type and call `ty.subst(substs)` to get a new version of `ty` with the substitutions made.
 
@@ -475,7 +475,7 @@ get a type and call `ty.subst(substs)` to get a new version of `ty` with the sub
 **Note on indices:** It is possible for the indices in `Param` to not match with what we expect. For
 example, the index could be out of bounds or it could be the index of a lifetime when we were
 expecting a type. These sorts of errors would be caught earlier in the compiler when translating
-from a `hir::Ty` to a `ty::Ty`. If they occur later, that is a compiler bug.
+from a `rustc_hir::Ty` to a `ty::Ty`. If they occur later, that is a compiler bug.
 
 ### `TypeFoldable` and `TypeFolder`