Merging upstream version 1.72.1+dfsg1.

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

12 files changed, 74 insertions, 20 deletions

diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md
index 58a476bdc..9f7c9cf1b 100644
--- a/src/doc/rustc-dev-guide/src/SUMMARY.md
+++ b/src/doc/rustc-dev-guide/src/SUMMARY.md
@@ -123,6 +123,7 @@
         - [The solver](./solve/the-solver.md)
         - [Canonicalization](./solve/canonicalization.md)
         - [Coinduction](./solve/coinduction.md)
+        - [Proof trees](./solve/proof-trees.md)
 - [Type checking](./type-checking.md)
     - [Method Lookup](./method-lookup.md)
     - [Variance](./variance.md)
diff --git a/src/doc/rustc-dev-guide/src/backend/implicit-caller-location.md b/src/doc/rustc-dev-guide/src/backend/implicit-caller-location.md
index 21554f5a4..cf100a2e5 100644
--- a/src/doc/rustc-dev-guide/src/backend/implicit-caller-location.md
+++ b/src/doc/rustc-dev-guide/src/backend/implicit-caller-location.md
@@ -260,7 +260,7 @@ originally specified. They have since been implemented following the path which
 to the author and reviewers.
 
 [RFC 2091]: https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md
-[attr-reference]: https://doc.rust-lang.org/reference/attributes/diagnostics.html#the-track_caller-attribute
+[attr-reference]: https://doc.rust-lang.org/reference/attributes/codegen.html#the-track_caller-attribute
 [intrinsic]: https://doc.rust-lang.org/nightly/core/intrinsics/fn.caller_location.html
 [wrapper]: https://doc.rust-lang.org/nightly/core/panic/struct.Location.html#method.caller
 [non-viable alternatives]: https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md#non-viable-alternatives
diff --git a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md
index eb674c8fe..6444aab5f 100644
--- a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md
+++ b/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md
@@ -67,8 +67,11 @@ You can install it with `cargo install --path src/tools/x`.
 
 ## Create a `config.toml`
 
-To start, run `./x.py setup`. This will do some initialization and create a
-`config.toml` for you with reasonable defaults.
+To start, run `./x.py setup` and select the `compiler` defaults. This will do some initialization
+and create a `config.toml` for you with reasonable defaults. If you use a different default (which
+you'll likely want to do if you want to contribute to an area of rust other than the compiler, such
+as rustdoc), make sure to read information about that default (located in `src/bootstrap/defaults`)
+as the build process may be different for other defaults.
 
 Alternatively, you can write `config.toml` by hand. See `config.example.toml` for all the available
 settings and explanations of them. See `src/bootstrap/defaults` for common settings to change.
diff --git a/src/doc/rustc-dev-guide/src/compiler-team.md b/src/doc/rustc-dev-guide/src/compiler-team.md
index 4570fd3fa..d5ba78c77 100644
--- a/src/doc/rustc-dev-guide/src/compiler-team.md
+++ b/src/doc/rustc-dev-guide/src/compiler-team.md
@@ -124,7 +124,7 @@ for you.
 
 [reviewer rotation]: https://github.com/rust-lang/rust/blob/36285c5de8915ecc00d91ae0baa79a87ed5858d5/triagebot.toml#L528-L577
 [triagebot]: https://github.com/rust-lang/triagebot/
-[automatically assigns]: https://github.com/rust-lang/triagebot/wiki/Assignment
+[automatically assigns]: https://forge.rust-lang.org/triagebot/pr-assignment.html
 
 Getting on the reviewer rotation is much appreciated as it lowers the
 review burden for all of us! However, if you don't have time to give
diff --git a/src/doc/rustc-dev-guide/src/const-eval.md b/src/doc/rustc-dev-guide/src/const-eval.md
index a7b1c8963..6d301823b 100644
--- a/src/doc/rustc-dev-guide/src/const-eval.md
+++ b/src/doc/rustc-dev-guide/src/const-eval.md
@@ -56,7 +56,7 @@ The basic rule for
 being permitted in the type system is that every value must be uniquely represented. In other
 words: a specific value must only be representable in one specific way. For example: there is only
 one way to represent an array of two integers as a `ValTree`:
-`ValTree::Branch(&[ValTree::Leaf(first_int), ValTree;:Leaf(second_int)])`.
+`ValTree::Branch(&[ValTree::Leaf(first_int), ValTree::Leaf(second_int)])`.
 Even though theoretically a `[u32; 2]` could be encoded in a `u64` and thus just be a
 `ValTree::Leaf(bits_of_two_u32)`, that is not a legal construction of `ValTree`
 (and is very complex to do, so it is unlikely anyone is tempted to do so).
diff --git a/src/doc/rustc-dev-guide/src/name-resolution.md b/src/doc/rustc-dev-guide/src/name-resolution.md
index 1dbc95ead..93c2a3eb7 100644
--- a/src/doc/rustc-dev-guide/src/name-resolution.md
+++ b/src/doc/rustc-dev-guide/src/name-resolution.md
@@ -91,8 +91,8 @@ part of another, it doesn't mean the name visible in the outer one is also
 visible in the inner one, or that it refers to the same thing.
 
 To cope with that, the compiler introduces the concept of Ribs. This is
-abstraction of a scope. Every time the set of visible names potentially changes,
-a new rib is pushed onto a stack. The places where this can happen includes for
+an abstraction of a scope. Every time the set of visible names potentially changes,
+a new rib is pushed onto a stack. The places where this can happen include for
 example:
 
 * The obvious places ‒ curly braces enclosing a block, function boundaries,
@@ -103,8 +103,8 @@ example:
 
 When searching for a name, the stack of ribs is traversed from the innermost
 outwards. This helps to find the closest meaning of the name (the one not
-shadowed by anything else). The transition to outer rib may also change the
-rules what names are usable ‒ if there are nested functions (not closures),
+shadowed by anything else). The transition to outer rib may also affect
+what names are usable ‒ if there are nested functions (not closures),
 the inner one can't access parameters and local bindings of the outer one,
 even though they should be visible by ordinary scoping rules. An example:
 
diff --git a/src/doc/rustc-dev-guide/src/notification-groups/about.md b/src/doc/rustc-dev-guide/src/notification-groups/about.md
index 260c59c24..a85c4a505 100644
--- a/src/doc/rustc-dev-guide/src/notification-groups/about.md
+++ b/src/doc/rustc-dev-guide/src/notification-groups/about.md
@@ -14,7 +14,7 @@ Of course, you don't have to wait for new issues to be tagged! If you
 prefer, you can use the Github label for a notification group to
 search for existing issues that haven't been claimed yet.
 
-[claim the issue]: https://github.com/rust-lang/triagebot/wiki/Assignment
+[claim the issue]: https://forge.rust-lang.org/triagebot/issue-assignment.html
 
 ## List of notification groups
 
@@ -95,5 +95,5 @@ or contributors, and is typically done as part of compiler team
 triage.**
 
 [rustbot]: https://github.com/rust-lang/triagebot/
-[`ping`]: https://github.com/rust-lang/triagebot/wiki/Pinging
+[`ping`]: https://forge.rust-lang.org/triagebot/pinging.html
 [`triagebot.toml`]: https://github.com/rust-lang/rust/blob/master/triagebot.toml
diff --git a/src/doc/rustc-dev-guide/src/rustbot.md b/src/doc/rustc-dev-guide/src/rustbot.md
index 5350f44ef..0959224f0 100644
--- a/src/doc/rustc-dev-guide/src/rustbot.md
+++ b/src/doc/rustc-dev-guide/src/rustbot.md
@@ -44,13 +44,13 @@ the `@rustbot` command will look like this:
     @rustbot label -S-waiting-on-author +S-waiting-on-review
 
 The syntax for this command is pretty loose, so there are other variants of this
-command invocation. For more details, see [the wiki page about labeling][labeling].
+command invocation. For more details, see [the docs page about labeling][labeling].
 
-[labeling]: https://github.com/rust-lang/triagebot/wiki/Labeling
+[labeling]: https://forge.rust-lang.org/triagebot/labeling.html
 
 ## Other commands
 
-If you are interested in seeing what `@rustbot` is capable of, check out its [wiki],
+If you are interested in seeing what `@rustbot` is capable of, check out its [documentation],
 which is meant as a reference for the bot and should be kept up to date every time the
 bot gets an upgrade.
 
@@ -58,6 +58,6 @@ bot gets an upgrade.
 existing commands or suggestions for new commands, feel free to reach out
 [on Zulip][zulip] or file an issue in [the triagebot repository][repo]
 
-[wiki]: https://github.com/rust-lang/triagebot/wiki
+[documentation]: https://forge.rust-lang.org/triagebot/index.html
 [zulip]: https://rust-lang.zulipchat.com/#narrow/stream/224082-t-release.2Ftriagebot
 [repo]: https://github.com/rust-lang/triagebot/
diff --git a/src/doc/rustc-dev-guide/src/solve/proof-trees.md b/src/doc/rustc-dev-guide/src/solve/proof-trees.md
new file mode 100644
index 000000000..e0904d946
--- /dev/null
+++ b/src/doc/rustc-dev-guide/src/solve/proof-trees.md
@@ -0,0 +1,50 @@
+# Proof trees
+
+The trait solver can optionally emit a "proof tree", a tree representation of what
+happened while trying to prove a goal.
+
+The used datastructures for which are currently stored in
+[`rustc_middle::traits::solve::inspect`].
+
+## What are they used for
+
+There are 3 intended uses for proof trees. These uses are not yet implemented as
+the representation of proof trees itself is currently still unstable.
+
+They should be used by type system diagnostics to get information about
+why a goal failed or remained ambiguous. They should be used by rustdoc to get the
+auto-trait implementations for user-defined types, and they should be usable to
+vastly improve the debugging experience of the trait solver.
+
+For debugging you can use `-Zdump-solver-proof-tree` which dumps the proof tree
+for all goals proven by the trait solver in the current session.
+
+## Requirements and design constraints for proof trees
+
+The trait solver uses [Canonicalization] and uses completely separate `InferCtxt` for
+each nested goal. Both diagnostics and auto-traits in rustdoc need to correctly
+handle "looking into nested goals". Given a goal like `Vec<Vec<?x>>: Debug`, we
+canonicalize to `exists<T0> Vec<Vec<T0>>: Debug`, instantiate that goal as
+`Vec<Vec<?0>>: Debug`, get a nested goal `Vec<?0>: Debug`, canonicalize this to get
+`exists<T0> Vec<T0>: Debug`, instantiate this as `Vec<?0>: Debug` which then results
+in a nested `?0: Debug` goal which is ambiguous.
+
+We need to be able to figure out that `?x` corresponds to `?0` in the nested queries.
+
+The debug output should also accurately represent the state at each point in the solver.
+This means that even though a goal like `fn(?0): FnOnce(i32)` infers `?0` to `i32`, the
+proof tree should still store `fn(<some infer var>): FnOnce(i32)` instead of
+`fn(i32): FnOnce(i32)` until we actually infer `?0` to `i32`.
+
+## The current implementation and how to extract information from proof trees.
+
+Proof trees will be quite involved as they should accurately represent everything the
+trait solver does, which includes fixpoint iterations and performance optimizations.
+
+We intend to provide a lossy user interface for all usecases.
+
+TODO: implement this user interface and explain how it can be used here.
+
+
+[`rustc_middle::traits::solve::inspect`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/traits/solve/inspect/index.html
+[Canonicalization]: ./canonicalization.md
\ No newline at end of file
diff --git a/src/doc/rustc-dev-guide/src/tests/compiletest.md b/src/doc/rustc-dev-guide/src/tests/compiletest.md
index f066992dc..d4730c5b4 100644
--- a/src/doc/rustc-dev-guide/src/tests/compiletest.md
+++ b/src/doc/rustc-dev-guide/src/tests/compiletest.md
@@ -363,7 +363,7 @@ your test, causing separate files to be generated for 32bit and 64bit systems.
 [`tests/mir-opt`]: https://github.com/rust-lang/rust/tree/master/tests/mir-opt
 
 
-### Run-make tests
+### `run-make` tests
 
 The tests in [`tests/run-make`] are general-purpose tests using Makefiles
 which provide the ultimate in flexibility.
@@ -371,8 +371,8 @@ These should be used as a last resort.
 If possible, you should use one of the other test suites.
 If there is some minor feature missing which you need for your test,
 consider extending compiletest to add a header command for what you need.
-However, sometimes just running a bunch of commands is really what you
-need, `run-make` is here to the rescue!
+However, if running a bunch of commands is really what you need,
+`run-make` is here to the rescue!
 
 Each test should be in a separate directory with a `Makefile` indicating the
 commands to run.
diff --git a/src/doc/rustc-dev-guide/src/thir.md b/src/doc/rustc-dev-guide/src/thir.md
index 2a811be3d..2197cad71 100644
--- a/src/doc/rustc-dev-guide/src/thir.md
+++ b/src/doc/rustc-dev-guide/src/thir.md
@@ -82,7 +82,7 @@ Thir {
                 neg: false,
             },
         },
-        // expression 1, scope surronding literal 1
+        // expression 1, scope surrounding literal 1
         Expr {
             ty: i32,
             temp_lifetime: Some(
diff --git a/src/doc/rustc-dev-guide/src/traits/resolution.md b/src/doc/rustc-dev-guide/src/traits/resolution.md
index 639ebbdec..8fd4272a8 100644
--- a/src/doc/rustc-dev-guide/src/traits/resolution.md
+++ b/src/doc/rustc-dev-guide/src/traits/resolution.md
@@ -247,7 +247,7 @@ In this second selection, we do not consider any where-clauses to be in scope
 because we know that each resolution will resolve to a particular impl.
 
 One interesting twist has to do with nested obligations. In general, in codegen,
-we only to figure out which candidate applies, we do not care about nested obligations,
+we only need to figure out which candidate applies, and we do not care about nested obligations,
 as these are already assumed to be true. Nonetheless, we *do* currently fulfill all of them.
 That is because it can sometimes inform the results of type inference.
 That is, we do not have the full substitutions in terms of the type variables