Merging upstream version 1.71.1+dfsg1.

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

10 files changed, 102 insertions, 7 deletions

diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md
index b01cb6797..58a476bdc 100644
--- a/src/doc/rustc-dev-guide/src/SUMMARY.md
+++ b/src/doc/rustc-dev-guide/src/SUMMARY.md
@@ -24,6 +24,7 @@
         - [Test headers](./tests/headers.md)
     - [Performance testing](./tests/perf.md)
     - [Crater](./tests/crater.md)
+    - [Suggest tests tool](./tests/suggest-tests.md)
 - [Debugging the compiler](./compiler-debugging.md)
     - [Using the tracing/logging instrumentation](./tracing.md)
 - [Profiling the compiler](./profiling.md)
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 59893bdc1..eb674c8fe 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
@@ -99,10 +99,10 @@ Also, note that `x.py` supports all kinds of path suffixes for `compiler`, `libr
 and `src/tools` directories. So, you can simply run `x.py test tidy` instead of
 `x.py test src/tools/tidy`. Or, `x.py build std` instead of `x.py build library/std`.
 
-[rust-analyzer]: ./building/suggested.html#configuring-rust-analyzer-for-rustc
+[rust-analyzer]: suggested.html#configuring-rust-analyzer-for-rustc
 
-See the chapters on [building](./building/how-to-build-and-run.md),
-[testing](./tests/intro.md), and [rustdoc](./rustdoc.md) for more details.
+See the chapters on [building](how-to-build-and-run),
+[testing](../tests/intro), and [rustdoc](../rustdoc) for more details.
 
 ### Building the compiler
 
diff --git a/src/doc/rustc-dev-guide/src/building/suggested.md b/src/doc/rustc-dev-guide/src/building/suggested.md
index 3049d87db..9dcc795f2 100644
--- a/src/doc/rustc-dev-guide/src/building/suggested.md
+++ b/src/doc/rustc-dev-guide/src/building/suggested.md
@@ -109,6 +109,23 @@ the problem. A nice side-effect of this style is that you are left
 with a fairly fine-grained set of commits at the end, all of which
 build and pass tests. This often helps reviewing.
 
+## `x suggest`
+
+The `x suggest` subcommand suggests (and runs) a subset of the extensive
+`rust-lang/rust` tests based on files you have changed. This is especially useful
+for new contributors who have not mastered the arcane `x` flags yet and more
+experienced contributors as a shorthand for reducing mental effort. In all cases
+it is useful not to run the full tests (which can take on the order of tens of
+minutes) and just run a subset which are relevant to your changes. For example,
+running `tidy` and `linkchecker` is useful when editing Markdown files, whereas UI
+tests are much less likely to be helpful. While `x suggest` is a useful tool, it
+does not guarantee perfect coverage (just as PR CI isn't a substitute for bors).
+See the [dedicated chapter](../tests/suggest-tests.md) for more information and
+contribution instructions. 
+
+Please note that `x suggest` is in a beta state currently and the tests that it
+will suggest are limited.
+
 ## Configuring `rustup` to use nightly
 
 Some parts of the bootstrap process uses pinned, nightly versions of tools like
@@ -322,3 +339,13 @@ pkgs.mkShell {
   RUST_BOOTSTRAP_CONFIG = config;
 }
 ```
+
+## Shell Completions
+
+If you use Bash, Fish or PowerShell, you can find automatically-generated shell completion scripts for `x.py` in [`src/etc/completions`](https://github.com/rust-lang/rust/tree/master/src/etc/completions).
+Zsh support will also be included once issues with [`clap_complete`](https://crates.io/crates/clap_complete) have been resolved.
+
+You can use `source ./src/etc/completions/x.py.<extension>`
+to load completions for your shell of choice,
+or `source .\src\etc\completions\x.py.ps1` for PowerShell.
+Adding this to your shell's startup script (e.g. `.bashrc`) will automatically load this completion.
\ No newline at end of file
diff --git a/src/doc/rustc-dev-guide/src/getting-started.md b/src/doc/rustc-dev-guide/src/getting-started.md
index d5c948994..297873d98 100644
--- a/src/doc/rustc-dev-guide/src/getting-started.md
+++ b/src/doc/rustc-dev-guide/src/getting-started.md
@@ -90,7 +90,7 @@ filtering the search to areas you're interested in. For example:
 Not all important or beginner work has issue labels.
 See below for how to find work that isn't labelled.
 
-[help-wanted-search]: https://github.com/issues?q=is%3Aopen+is%3Aissue+org%3Arust-lang+no%3Aassignee+label%3AE-easy%2C%22good+first+issue%22%2Cgood-first-issue%2CE-medium%2CE-help-wanted%2CE-mentor
+[help-wanted-search]: https://github.com/issues?q=is%3Aopen+is%3Aissue+org%3Arust-lang+no%3Aassignee+label%3AE-easy%2C%22good+first+issue%22%2Cgood-first-issue%2CE-medium%2CE-help-wanted%2CE-mentor+-label%3AS-blocked+
 [Triage]: ./contributing.md#issue-triage
 
 ### Recurring work
@@ -169,7 +169,7 @@ incredibly helpful:
 
 ## Cloning and Building
 
-See ["How to build and run the compiler"](./building//how-to-build-and-run.md).
+See ["How to build and run the compiler"](./building/how-to-build-and-run.md).
 
 ## Contributor Procedures
 
diff --git a/src/doc/rustc-dev-guide/src/hir-debugging.md b/src/doc/rustc-dev-guide/src/hir-debugging.md
index 8788ad4de..c25a558a0 100644
--- a/src/doc/rustc-dev-guide/src/hir-debugging.md
+++ b/src/doc/rustc-dev-guide/src/hir-debugging.md
@@ -3,6 +3,6 @@
 The `-Z unpretty=hir-tree` flag will dump out the HIR.
 
 If you are trying to correlate `NodeId`s or `DefId`s with source code, the
-`--pretty expanded,identified` flag may be useful.
+`-Z unpretty=expanded,identified` flag may be useful.
 
 TODO: anything else? [#1159](https://github.com/rust-lang/rustc-dev-guide/issues/1159)
diff --git a/src/doc/rustc-dev-guide/src/mir/optimizations.md b/src/doc/rustc-dev-guide/src/mir/optimizations.md
index 037cf5874..293d2fe91 100644
--- a/src/doc/rustc-dev-guide/src/mir/optimizations.md
+++ b/src/doc/rustc-dev-guide/src/mir/optimizations.md
@@ -131,6 +131,6 @@ needed for correctness), then fuel should not be used. An example of this is `Pr
 perform optimizations. In these situations, we should allow for the initial gathering pass
 and then check fuel as close to the mutation as possible. This allows for the best
 debugging experience, because we can determine where in the list of candidates an optimization
-may have been misapplied. Examples of this are `InstCombine` and `ConstantPropagation`.
+may have been misapplied. Examples of this are `InstSimplify` and `ConstantPropagation`.
 
 [consideroptimizing]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.TyCtxt.html#method.consider_optimizing
diff --git a/src/doc/rustc-dev-guide/src/solve/trait-solving.md b/src/doc/rustc-dev-guide/src/solve/trait-solving.md
index 71f6581c2..b0cd9af6c 100644
--- a/src/doc/rustc-dev-guide/src/solve/trait-solving.md
+++ b/src/doc/rustc-dev-guide/src/solve/trait-solving.md
@@ -96,6 +96,10 @@ Trait solving during codegen should have the same result as during typeck. As we
 all free regions during codegen we must not rely on them during typeck. A noteworthy example
 is special behavior for `'static`.
 
+We also have to be careful with relying on equality of regions in the trait solver.
+This is fine for codegen, as we treat all erased regions are equal. We can however
+lose equality information from HIR to MIR typeck.
+
 ### 7. Removing ambiguity makes strictly more things compile
 
 We *should* not rely on ambiguity for things to compile.
diff --git a/src/doc/rustc-dev-guide/src/tests/headers.md b/src/doc/rustc-dev-guide/src/tests/headers.md
index 5b71f3ea1..682c96b44 100644
--- a/src/doc/rustc-dev-guide/src/tests/headers.md
+++ b/src/doc/rustc-dev-guide/src/tests/headers.md
@@ -52,6 +52,8 @@ found in [`header.rs`] from the compiletest source.
     * [`stderr-per-bitwidth`](ui.md#output-comparison) — separate output per bit width
     * [`dont-check-compiler-stderr`](ui.md#output-comparison) — don't validate stderr
     * [`dont-check-compiler-stdout`](ui.md#output-comparison) — don't validate stdout
+    * [`compare-output-lines-by-subset`](ui.md#output-comparison) — checks output by
+      line subset
 * [Building auxiliary crates](compiletest.md#building-auxiliary-crates)
     * `aux-build`
     * `aux-crate`
@@ -72,6 +74,7 @@ found in [`header.rs`] from the compiletest source.
 * [Environment variable headers](#environment-variable-headers)
     * `rustc-env`
     * `exec-env`
+    * `unset-exec-env`
     * `unset-rustc-env`
 * [Miscellaneous headers](#miscellaneous-headers)
     * `compile-flags` — adds compiler flags
@@ -177,6 +180,8 @@ The following headers affect environment variables.
   form `KEY=VALUE`.
 * `exec-env` is an environment variable to set when executing a test of the
   form `KEY=VALUE`.
+* `unset-exec-env` specifies an environment variable to unset when executing a
+  test.
 * `unset-rustc-env` specifies an environment variable to unset when running
   `rustc`.
 
diff --git a/src/doc/rustc-dev-guide/src/tests/suggest-tests.md b/src/doc/rustc-dev-guide/src/tests/suggest-tests.md
new file mode 100644
index 000000000..f6b6d1537
--- /dev/null
+++ b/src/doc/rustc-dev-guide/src/tests/suggest-tests.md
@@ -0,0 +1,55 @@
+# Suggest tests tool
+
+This chapter is about the internals of and contribution instructions for the
+`suggest-tests` tool. For a high-level overview of the tool, see
+[this section](../building/suggested.md#x-suggest). This tool is currently in a
+beta state and is tracked by [this](https://github.com/rust-lang/rust/issues/109933)
+issue on Github. Currently the number of tests it will suggest are very limited
+in scope, we are looking to expand this (contributions welcome!).
+
+## Internals
+
+The tool is defined in a separate crate ([`src/tools/suggest-tests`](https://github.com/rust-lang/rust/blob/master/src/tools/suggest-tests))
+which outputs suggestions which are parsed by a shim in bootstrap
+([`src/bootstrap/suggest.rs`](https://github.com/rust-lang/rust/blob/master/src/bootstrap/suggest.rs)).
+The only notable thing the bootstrap shim does is (when invoked with the
+`--run` flag) use bootstrap's internal mechanisms to create a new `Builder` and
+uses it to invoke the suggested commands. The `suggest-tests` crate is where the
+fun happens, two kinds of suggestions are defined: "static" and "dynamic"
+suggestions.
+
+### Static suggestions
+
+Defined [here](https://github.com/rust-lang/rust/blob/master/src/tools/suggest-tests/src/static_suggestions.rs).
+Static suggestions are simple: they are just [globs](https://crates.io/crates/glob)
+which map to a `x` command. In `suggest-tests`, this is implemented with a
+simple `macro_rules` macro.
+
+### Dynamic suggestions
+
+Defined [here](https://github.com/rust-lang/rust/blob/master/src/tools/suggest-tests/src/dynamic_suggestions.rs).
+These are more complicated than static suggestions and are implemented as
+functions with the following signature: `fn(&Path) -> Vec<Suggestion>`. In
+other words, each suggestion takes a path to a modified file and (after running
+arbitrary Rust code) can return any number of suggestions, or none. Dynamic
+suggestions are useful for situations where fine-grained control over
+suggestions is needed. For example, modifications to the `compiler/xyz/` path
+should trigger the `x test compiler/xyz` suggestion. In the future, dynamic
+suggestions might even read file contents to determine if (what) tests should
+run.
+
+## Adding a suggestion
+
+The following steps should serve as a rough guide to add suggestions to
+`suggest-tests` (very welcome!):
+
+1. Determine the rules for your suggestion. Is it simple and operates only on
+   a single path or does it match globs? Does it need fine-grained control over
+   the resulting command or does "one size fit all"?
+2. Based on the previous step, decide if your suggestion should be implemented
+   as either static or dynamic.
+3. Implement the suggestion. If it is dynamic then a test is highly recommended,
+   to verify that your logic is correct and to give an example of the suggestion.
+   See the [tests.rs](https://github.com/rust-lang/rust/blob/master/src/tools/suggest-tests/src/tests.rs)
+   file.
+4. Open a PR implementing your suggestion. **(TODO: add example PR)**
diff --git a/src/doc/rustc-dev-guide/src/tests/ui.md b/src/doc/rustc-dev-guide/src/tests/ui.md
index cc32ad1d3..d94d8cc4e 100644
--- a/src/doc/rustc-dev-guide/src/tests/ui.md
+++ b/src/doc/rustc-dev-guide/src/tests/ui.md
@@ -84,6 +84,9 @@ check for output files:
   [Normalization](#normalization)).
 * `dont-check-compiler-stderr` — Ignores stderr from the compiler.
 * `dont-check-compiler-stdout` — Ignores stdout from the compiler.
+* `compare-output-lines-by-subset` — Checks that the output contains the
+  contents of the stored output files by lines opposed to checking for strict
+  equality.
 
 UI tests run with with `-Zdeduplicate-diagnostics=no` flag which disables
 rustc's built-in diagnostic deduplication mechanism.