Merge branch 'master' into update-bootstrap-related-docs

src/appendix/glossary.md

@@ -23,7 +23,7 @@ Term                                                  | Meaning
 <span id="double-ptr">double pointer</span>    &nbsp; |  A pointer with additional metadata. See "fat pointer" for more.
 <span id="drop-glue">drop glue</span>          &nbsp; |  (internal) compiler-generated instructions that handle calling the destructors (`Drop`) for data types.
 <span id="dst">DST</span>                      &nbsp; |  Short for Dynamically-Sized Type, this is a type for which the compiler cannot statically know the size in memory (e.g. `str` or `[u8]`). Such types don't implement `Sized` and cannot be allocated on the stack. They can only occur as the last field in a struct. They can only be used behind a pointer (e.g. `&str` or `&[u8]`).
-<span id="ebl">early-bound lifetime</span>     &nbsp; |  A lifetime region that is substituted at its definition site. Bound in an item's `Generics` and substituted using a `Substs`. Contrast with **late-bound lifetime**. ([see more](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.RegionKind.html#bound-regions))
+<span id="ebl">early-bound lifetime</span>     &nbsp; |  A lifetime region that is substituted at its definition site. Bound in an item's `Generics` and substituted using a `Substs`. Contrast with **late-bound lifetime**. ([see more](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_type_ir/sty/enum.RegionKind.html#bound-regions))
 <span id="empty-type">empty type</span>        &nbsp; |  see "uninhabited type".
 <span id="fat-ptr">fat pointer</span>          &nbsp; |  A two word value carrying the address of some value, along with some further information necessary to put the value to use. Rust includes two kinds of "fat pointers": references to slices, and trait objects. A reference to a slice carries the starting address of the slice and its length. A trait object carries a value's address and a pointer to the trait's implementation appropriate to that value. "Fat pointers" are also known as "wide pointers", and "double pointers".
 <span id="free-var">free variable</span>       &nbsp; |  A "free variable" is one that is not bound within an expression or term; see [the background chapter for more](./background.md#free-vs-bound)
@@ -42,7 +42,7 @@ Term                                                  | Meaning
 <span id="irlo">IRLO</span>                    &nbsp; |  `IRLO` or `irlo` is sometimes used as an abbreviation for [internals.rust-lang.org](https://internals.rust-lang.org).
 <span id="item">item</span>                    &nbsp; |  A kind of "definition" in the language, such as a static, const, use statement, module, struct, etc. Concretely, this corresponds to the `Item` type.
 <span id="lang-item">lang item</span>          &nbsp; |  Items that represent concepts intrinsic to the language itself, such as special built-in traits like `Sync` and `Send`; or traits representing operations such as `Add`; or functions that are called by the compiler. ([see more](https://doc.rust-lang.org/1.9.0/book/lang-items.html))
-<span id="lbl">late-bound lifetime</span>      &nbsp; |  A lifetime region that is substituted at its call site. Bound in a HRTB and substituted by specific functions in the compiler, such as `liberate_late_bound_regions`. Contrast with **early-bound lifetime**. ([see more](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.RegionKind.html#bound-regions))
+<span id="lbl">late-bound lifetime</span>      &nbsp; |  A lifetime region that is substituted at its call site. Bound in a HRTB and substituted by specific functions in the compiler, such as `liberate_late_bound_regions`. Contrast with **early-bound lifetime**. ([see more](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_type_ir/sty/enum.RegionKind.html#bound-regions))
 <span id="local-crate">local crate</span>      &nbsp; |  The crate currently being compiled. This is in contrast to "upstream crates" which refer to dependencies of the local crate.
 <span id="lto">LTO</span>                      &nbsp; |  Short for Link-Time Optimizations, this is a set of optimizations offered by LLVM that occur just before the final binary is linked. These include optimizations like removing functions that are never used in the final program, for example. _ThinLTO_ is a variant of LTO that aims to be a bit more scalable and efficient, but possibly sacrifices some optimizations. You may also read issues in the Rust repo about "FatLTO", which is the loving nickname given to non-Thin LTO. LLVM documentation: [here][lto] and [here][thinlto].
 <span id="llvm">[LLVM]</span>                  &nbsp; |  (actually not an acronym :P) an open-source compiler backend. It accepts LLVM IR and outputs native binaries. Various languages (e.g. Rust) can then implement a compiler front-end that outputs LLVM IR and use LLVM to compile to all the platforms LLVM supports.

src/borrow_check/region_inference/lifetime_parameters.md

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

src/building/bootstrapping.md

@@ -2,7 +2,6 @@
 
 <!-- toc -->
 
-
 [*Bootstrapping*][boot] is the process of using a compiler to compile itself.
 More accurately, it means using an older compiler to compile a newer version
 of the same compiler.
@@ -16,6 +15,11 @@ version.
 This is exactly how `x.py` works: it downloads the current beta release of
 rustc, then uses it to compile the new compiler.
 
+Note that this documentation mostly covers user-facing information. See
+[bootstrap/README.md][bootstrap-internals] to read about bootstrap internals.
+
+[bootstrap-internals]: https://github.com/rust-lang/rust/blob/master/src/bootstrap/README.md
+
 ## Stages of bootstrapping
 
 Compiling `rustc` is done in stages. Here's a diagram, adapted from Joshua Nelson's
@@ -389,7 +393,7 @@ variables.
 [cc-rs crate]: https://github.com/rust-lang/cc-rs
 [env-vars]: https://github.com/rust-lang/cc-rs#external-configuration-via-environment-variables
 
-### Clarification of build command's stdout
+## Clarification of build command's stdout
 
 In this part, we will investigate the build command's stdout in an action
 (similar, but more detailed and complete documentation compare to topic above).
@@ -408,17 +412,17 @@ Building stage1 tool rust-analyzer-proc-macro-srv (x86_64-unknown-linux-gnu)
 Building rustdoc for stage1 (x86_64-unknown-linux-gnu)
 ```
 
-#### Building stage0 {std,compiler} artifacts
+### Building stage0 {std,compiler} artifacts
 
 These steps use the provided (downloaded, usually) compiler to compile the
 local Rust source into libraries we can use.
 
-#### Copying stage0 {std,rustc}
+### Copying stage0 {std,rustc}
 
 This copies the library and compiler artifacts from Cargo into
 `stage0-sysroot/lib/rustlib/{target-triple}/lib`
 
-#### Assembling stage1 compiler
+### Assembling stage1 compiler
 
 This copies the libraries we built in "building stage0 ... artifacts" into
 the stage1 compiler's lib directory. These are the host libraries that the

src/building/how-to-build-and-run.md

@@ -122,16 +122,10 @@ you will likely need to build at some point; for example, if you want
 to run the entire test suite).
 
 ```bash
-rustup toolchain link stage1 build/<host-triple>/stage1
-rustup toolchain link stage2 build/<host-triple>/stage2
+rustup toolchain link stage1 build/host/stage1
+rustup toolchain link stage2 build/host/stage2
 ```
 
-The `<host-triple>` would typically be one of the following:
-
-- Linux: `x86_64-unknown-linux-gnu`
-- Mac: `x86_64-apple-darwin` or `aarch64-apple-darwin`
-- Windows: `x86_64-pc-windows-msvc`
-
 Now you can run the `rustc` you built with. If you run with `-vV`, you
 should see a version number ending in `-dev`, indicating a build from
 your local environment:

src/building/suggested.md

@@ -34,7 +34,7 @@ you can write: <!-- date-check: nov 2022 --><!-- the date comment is for the edi
         "--json-output"
     ],
     "rust-analyzer.rustfmt.overrideCommand": [
-        "./build/host/stage0/bin/rustfmt",
+        "./build/host/rustfmt/bin/rustfmt",
         "--edition=2021"
     ],
     "rust-analyzer.procMacro.server": "./build/host/stage0/libexec/rust-analyzer-proc-macro-srv",

src/constants.md

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

src/implementing_new_features.md

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

src/llvm-coverage-instrumentation.md

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

src/mir/visitor.md

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

src/profiling/with_perf.md

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

src/solve/the-solver.md

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

src/solve/trait-solving.md

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