Merge pull request #2477 from rust-lang/rustc-pull

Rustc pull update

19 files changed, 195 insertions, 307 deletions

diff --git a/src/doc/book b/src/doc/book
-Subproject 634724ea85ebb08a542970bf8871ac8b0f77fd1
+Subproject 4433c9f0cad8460bee05ede040587f8a1fa3f1d
diff --git a/src/doc/reference b/src/doc/reference
-Subproject 8e0f593a30f3b56ddb0908fb7ab9249974e0873
+Subproject d4c66b346f4b72d29e70390a3fa3ea7d4e064db
diff --git a/src/doc/rust-by-example b/src/doc/rust-by-example
-Subproject 21f4e32b8b40d36453fae16ec07ad4b857c445b
+Subproject 9baa9e863116cb9524a177d5a5c475baac18928
diff --git a/src/doc/rustc-dev-guide/rust-version b/src/doc/rustc-dev-guide/rust-version
index 86d35b31498..30ba3070e1f 100644
--- a/src/doc/rustc-dev-guide/rust-version
+++ b/src/doc/rustc-dev-guide/rust-version
@@ -1 +1 @@
-14346303d760027e53214e705109a62c0f00b214
+d1d8e386c5e84c4ba857f56c3291f73c27e2d62a
diff --git a/src/doc/rustc-dev-guide/src/building/bootstrapping/writing-tools-in-bootstrap.md b/src/doc/rustc-dev-guide/src/building/bootstrapping/writing-tools-in-bootstrap.md
index 6046d5b133d..41d0cf8d9fb 100644
--- a/src/doc/rustc-dev-guide/src/building/bootstrapping/writing-tools-in-bootstrap.md
+++ b/src/doc/rustc-dev-guide/src/building/bootstrapping/writing-tools-in-bootstrap.md
@@ -4,7 +4,7 @@ There are three types of tools you can write in bootstrap:
 
 - **`Mode::ToolBootstrap`**
   Use this for tools that don’t need anything from the in-tree compiler and can run with the stage0 `rustc`.
-  The output is placed in the "stage0-bootstrap-tools" directory. This mode is for general-purpose tools built
+  The output is placed in the "bootstrap-tools" directory. This mode is for general-purpose tools built
   entirely with the stage0 compiler, including target libraries and only works for stage 0.
 
 - **`Mode::ToolStd`**
diff --git a/src/doc/rustc-dev-guide/src/implementing_new_features.md b/src/doc/rustc-dev-guide/src/implementing_new_features.md
index d7561bbbad2..5d0e875cbc1 100644
--- a/src/doc/rustc-dev-guide/src/implementing_new_features.md
+++ b/src/doc/rustc-dev-guide/src/implementing_new_features.md
@@ -156,8 +156,8 @@ a new unstable feature:
    [`incomplete_features` lint]: https://doc.rust-lang.org/rustc/lints/listing/warn-by-default.html#incomplete-features
 
    ```rust ignore
-   /// Allows unsized rvalues at arguments and parameters.
-   (incomplete, unsized_locals, "CURRENT_RUSTC_VERSION", Some(48055), None),
+   /// Allows deref patterns.
+   (incomplete, deref_patterns, "CURRENT_RUSTC_VERSION", Some(87121), None),
    ```
 
    To avoid [semantic merge conflicts], please use `CURRENT_RUSTC_VERSION` instead of `1.70` or
diff --git a/src/doc/rustc-dev-guide/src/tests/ui.md b/src/doc/rustc-dev-guide/src/tests/ui.md
index 25d3efdbb82..9e4a11044e8 100644
--- a/src/doc/rustc-dev-guide/src/tests/ui.md
+++ b/src/doc/rustc-dev-guide/src/tests/ui.md
@@ -113,6 +113,8 @@ Compiletest makes the following replacements on the compiler output:
 - The base directory where the test's output goes is replaced with
   `$TEST_BUILD_DIR`. This only comes up in a few rare circumstances. Example:
   `/path/to/rust/build/x86_64-unknown-linux-gnu/test/ui`
+- The real directory to the standard library source is replaced with `$SRC_DIR_REAL`.
+- The real directory to the compiler source is replaced with `$COMPILER_DIR_REAL`.
 - Tabs are replaced with `\t`.
 - Backslashes (`\`) are converted to forward slashes (`/`) within paths (using a
   heuristic). This helps normalize differences with Windows-style paths.
diff --git a/src/doc/rustc/src/SUMMARY.md b/src/doc/rustc/src/SUMMARY.md
index a3939e5a5c4..201a5503079 100644
--- a/src/doc/rustc/src/SUMMARY.md
+++ b/src/doc/rustc/src/SUMMARY.md
@@ -113,6 +113,7 @@
     - [\*-unknown-openbsd](platform-support/openbsd.md)
     - [\*-unknown-redox](platform-support/redox.md)
     - [\*-unknown-uefi](platform-support/unknown-uefi.md)
+    - [\*-unknown-windows-msvc](platform-support/windows-msvc.md)
     - [\*-uwp-windows-msvc](platform-support/uwp-windows-msvc.md)
     - [\*-wrs-vxworks](platform-support/vxworks.md)
     - [wasm32-wasip1](platform-support/wasm32-wasip1.md)
diff --git a/src/doc/rustc/src/command-line-arguments.md b/src/doc/rustc/src/command-line-arguments.md
index b704cee705b..d45ad1be27b 100644
--- a/src/doc/rustc/src/command-line-arguments.md
+++ b/src/doc/rustc/src/command-line-arguments.md
@@ -471,6 +471,9 @@ to customize the output:
 - `future-incompat` - includes a JSON message that contains a report if the
   crate contains any code that may fail to compile in the future.
 
+- `timings` - output a JSON message when a certain compilation "section"
+  (such as frontend analysis, code generation, linking) begins or ends.
+
 Note that it is invalid to combine the `--json` argument with the
 [`--color`](#option-color) argument, and it is required to combine `--json`
 with `--error-format=json`.
diff --git a/src/doc/rustc/src/json.md b/src/doc/rustc/src/json.md
index c853f34ee03..7421dd62108 100644
--- a/src/doc/rustc/src/json.md
+++ b/src/doc/rustc/src/json.md
@@ -298,6 +298,35 @@ appropriately. (This is needed by Cargo which shares the same dependencies
 across multiple build targets, so it should only report an unused dependency if
 its not used by any of the targets.)
 
+## Timings
+
+**This setting is currently unstable and requires usage of `-Zunstable-options`.**
+
+The `--timings` option will tell `rustc` to emit messages when a certain compilation
+section (such as code generation or linking) begins or ends. The messages currently have
+the following format:
+
+```json
+{
+    "$message_type": "section_timing", /* Type of this message */
+    "event": "start", /* Marks the "start" or "end" of the compilation section */
+    "name": "link",  /* The name of the compilation section */
+    // Opaque timestamp when the message was emitted, in microseconds
+    // The timestamp is currently relative to the beginning of the compilation session
+    "time": 12345
+}
+```
+
+Note that the JSON format of the `timings` messages is unstable and subject to change.
+
+Compilation sections can be nested; for example, if you encounter the start of "foo",
+then the start of "bar", then the end of "bar" and then the end of "bar", it means that the
+"bar" section happened as a part of the "foo" section.
+
+The timestamp should only be used for computing the duration of each section.
+
+We currently do not guarantee any specific section names to be emitted.
+
 [option-emit]: command-line-arguments.md#option-emit
 [option-error-format]: command-line-arguments.md#option-error-format
 [option-json]: command-line-arguments.md#option-json
diff --git a/src/doc/rustc/src/platform-support.md b/src/doc/rustc/src/platform-support.md
index 559e4867bbb..285b1e519b7 100644
--- a/src/doc/rustc/src/platform-support.md
+++ b/src/doc/rustc/src/platform-support.md
@@ -34,11 +34,11 @@ target | notes
 -------|-------
 [`aarch64-apple-darwin`](platform-support/apple-darwin.md) | ARM64 macOS (11.0+, Big Sur+)
 `aarch64-unknown-linux-gnu` | ARM64 Linux (kernel 4.1+, glibc 2.17+)
-`i686-pc-windows-msvc` | 32-bit MSVC (Windows 10+, Windows Server 2016+, Pentium 4) [^x86_32-floats-return-ABI] [^win32-msvc-alignment]
+[`i686-pc-windows-msvc`](platform-support/windows-msvc.md) | 32-bit MSVC (Windows 10+, Windows Server 2016+, Pentium 4) [^x86_32-floats-return-ABI] [^win32-msvc-alignment]
 `i686-unknown-linux-gnu` | 32-bit Linux (kernel 3.2+, glibc 2.17+, Pentium 4) [^x86_32-floats-return-ABI]
 [`x86_64-apple-darwin`](platform-support/apple-darwin.md) | 64-bit macOS (10.12+, Sierra+)
 [`x86_64-pc-windows-gnu`](platform-support/windows-gnu.md) | 64-bit MinGW (Windows 10+, Windows Server 2016+)
-`x86_64-pc-windows-msvc` | 64-bit MSVC (Windows 10+, Windows Server 2016+)
+[`x86_64-pc-windows-msvc`](platform-support/windows-msvc.md) | 64-bit MSVC (Windows 10+, Windows Server 2016+)
 `x86_64-unknown-linux-gnu` | 64-bit Linux (kernel 3.2+, glibc 2.17+)
 
 [^x86_32-floats-return-ABI]: Due to limitations of the C ABI, floating-point support on `i686` targets is non-compliant: floating-point return values are passed via an x87 register, so NaN payload bits can be lost. Functions with the default Rust ABI are not affected. See [issue #115567][x86-32-float-return-issue].
@@ -88,7 +88,8 @@ so Rustup may install the documentation for a similar tier 1 target instead.
 
 target | notes
 -------|-------
-`aarch64-pc-windows-msvc` | ARM64 Windows MSVC
+[`aarch64-pc-windows-gnullvm`](platform-support/windows-gnullvm.md) | ARM64 MinGW (Windows 10+), LLVM ABI
+[`aarch64-pc-windows-msvc`](platform-support/windows-msvc.md) | ARM64 Windows MSVC
 `aarch64-unknown-linux-musl` | ARM64 Linux with musl 1.2.3
 [`aarch64-unknown-linux-ohos`](platform-support/openharmony.md) | ARM64 OpenHarmony
 `arm-unknown-linux-gnueabi` | Armv6 Linux (kernel 3.2+, glibc 2.17)
@@ -105,6 +106,7 @@ target | notes
 [`riscv64gc-unknown-linux-gnu`](platform-support/riscv64gc-unknown-linux-gnu.md) | RISC-V Linux (kernel 4.20+, glibc 2.29)
 [`riscv64gc-unknown-linux-musl`](platform-support/riscv64gc-unknown-linux-musl.md) | RISC-V Linux (kernel 4.20+, musl 1.2.3)
 [`s390x-unknown-linux-gnu`](platform-support/s390x-unknown-linux-gnu.md) | S390x Linux (kernel 3.2+, glibc 2.17)
+[`x86_64-pc-windows-gnullvm`](platform-support/windows-gnullvm.md) | 64-bit x86 MinGW (Windows 10+), LLVM ABI
 [`x86_64-unknown-freebsd`](platform-support/freebsd.md) | 64-bit x86 FreeBSD
 [`x86_64-unknown-illumos`](platform-support/illumos.md) | illumos
 `x86_64-unknown-linux-musl` | 64-bit Linux with musl 1.2.3
@@ -147,7 +149,6 @@ target | std | notes
 [`aarch64-apple-ios-macabi`](platform-support/apple-ios-macabi.md) | ✓ | Mac Catalyst on ARM64
 [`aarch64-apple-ios-sim`](platform-support/apple-ios.md) | ✓ | Apple iOS Simulator on ARM64
 [`aarch64-linux-android`](platform-support/android.md) | ✓ | ARM64 Android
-[`aarch64-pc-windows-gnullvm`](platform-support/windows-gnullvm.md) | ✓ | ARM64 MinGW (Windows 10+), LLVM ABI
 [`aarch64-unknown-fuchsia`](platform-support/fuchsia.md) | ✓ | ARM64 Fuchsia
 `aarch64-unknown-none` | * | Bare ARM64, hardfloat
 `aarch64-unknown-none-softfloat` | * | Bare ARM64, softfloat
@@ -204,7 +205,6 @@ target | std | notes
 [`x86_64-apple-ios-macabi`](platform-support/apple-ios-macabi.md) | ✓ | Mac Catalyst on x86_64
 [`x86_64-fortanix-unknown-sgx`](platform-support/x86_64-fortanix-unknown-sgx.md) | ✓ | [Fortanix ABI] for 64-bit Intel SGX
 [`x86_64-linux-android`](platform-support/android.md) | ✓ | 64-bit x86 Android
-[`x86_64-pc-windows-gnullvm`](platform-support/windows-gnullvm.md) | ✓ | 64-bit x86 MinGW (Windows 10+), LLVM ABI
 [`x86_64-unknown-fuchsia`](platform-support/fuchsia.md) | ✓ | 64-bit x86 Fuchsia
 `x86_64-unknown-linux-gnux32` | ✓ | 64-bit Linux (x32 ABI) (kernel 4.15+, glibc 2.27)
 [`x86_64-unknown-none`](platform-support/x86_64-unknown-none.md) | * | Freestanding/bare-metal x86_64, softfloat
diff --git a/src/doc/rustc/src/platform-support/wasm32-unknown-unknown.md b/src/doc/rustc/src/platform-support/wasm32-unknown-unknown.md
index b67f49c3a38..1e74c47221c 100644
--- a/src/doc/rustc/src/platform-support/wasm32-unknown-unknown.md
+++ b/src/doc/rustc/src/platform-support/wasm32-unknown-unknown.md
@@ -207,120 +207,3 @@ conditionally compile code instead. This is notably different to the way native
 platforms such as x86\_64 work, and this is due to the fact that WebAssembly
 binaries must only contain code the engine understands. Native binaries work so
 long as the CPU doesn't execute unknown code dynamically at runtime.
-
-## Broken `extern "C"` ABI
-
-This target has what is considered a broken `extern "C"` ABI implementation at
-this time. Notably the same signature in Rust and C will compile to different
-WebAssembly functions and be incompatible. This is considered a bug and it will
-be fixed in a future version of Rust.
-
-For example this Rust code:
-
-```rust,ignore (does-not-link)
-#[repr(C)]
-struct MyPair {
-    a: u32,
-    b: u32,
-}
-
-extern "C" {
-    fn take_my_pair(pair: MyPair) -> u32;
-}
-
-#[no_mangle]
-pub unsafe extern "C" fn call_c() -> u32 {
-    take_my_pair(MyPair { a: 1, b: 2 })
-}
-```
-
-compiles to a WebAssembly module that looks like:
-
-```wasm
-(module
-  (import "env" "take_my_pair" (func $take_my_pair (param i32 i32) (result i32)))
-  (func $call_c
-    i32.const 1
-    i32.const 2
-    call $take_my_pair
-  )
-)
-```
-
-The function when defined in C, however, looks like
-
-```c
-struct my_pair {
-    unsigned a;
-    unsigned b;
-};
-
-unsigned take_my_pair(struct my_pair pair) {
-    return pair.a + pair.b;
-}
-```
-
-```wasm
-(module
-  (import "env" "__linear_memory" (memory 0))
-  (func $take_my_pair (param i32) (result i32)
-    local.get 0
-    i32.load offset=4
-    local.get 0
-    i32.load
-    i32.add
-  )
-)
-```
-
-Notice how Rust thinks `take_my_pair` takes two `i32` parameters but C thinks it
-only takes one.
-
-The correct definition of the `extern "C"` ABI for WebAssembly is located in the
-[WebAssembly/tool-conventions](https://github.com/WebAssembly/tool-conventions/blob/main/BasicCABI.md)
-repository. The `wasm32-unknown-unknown` target (and only this target, not other
-WebAssembly targets Rust support) does not correctly follow this document.
-
-Example issues in the Rust repository about this bug are:
-
-* [#115666](https://github.com/rust-lang/rust/issues/115666)
-* [#129486](https://github.com/rust-lang/rust/issues/129486)
-
-This current state of the `wasm32-unknown-unknown` backend is due to an
-unfortunate accident which got relied on. The `wasm-bindgen` project prior to
-0.2.89 was incompatible with the "correct" definition of `extern "C"` and it was
-seen as not worth the tradeoff of breaking `wasm-bindgen` historically to fix
-this issue in the compiler.
-
-Thanks to the heroic efforts of many involved in this, however, `wasm-bindgen`
-0.2.89 and later are compatible with the correct definition of `extern "C"` and
-the nightly compiler currently supports a `-Zwasm-c-abi` implemented in
-[#117919](https://github.com/rust-lang/rust/pull/117919). This nightly-only flag
-can be used to indicate whether the spec-defined version of `extern "C"` should
-be used instead of the "legacy" version of
-whatever-the-Rust-target-originally-implemented. For example using the above
-code you can see (lightly edited for clarity):
-
-```shell
-$ rustc +nightly -Zwasm-c-abi=spec foo.rs --target wasm32-unknown-unknown --crate-type lib --emit obj -O
-$ wasm-tools print foo.o
-(module
-  (import "env" "take_my_pair" (func $take_my_pair (param i32) (result i32)))
-  (func $call_c (result i32)
-    ;; ...
-  )
-  ;; ...
-)
-```
-
-which shows that the C and Rust definitions of the same function now agree like
-they should.
-
-The `-Zwasm-c-abi` compiler flag is tracked in
-[#122532](https://github.com/rust-lang/rust/issues/122532) and a lint was
-implemented in [#117918](https://github.com/rust-lang/rust/issues/117918) to
-help warn users about the transition if they're using `wasm-bindgen` 0.2.88 or
-prior. The current plan is to, in the future, switch `-Zwasm-c-api=spec` to
-being the default. Some time after that the `-Zwasm-c-abi` flag and the
-"legacy" implementation will all be removed. During this process users on a
-sufficiently updated version of `wasm-bindgen` should not experience breakage.
diff --git a/src/doc/rustc/src/platform-support/windows-gnullvm.md b/src/doc/rustc/src/platform-support/windows-gnullvm.md
index f3dc73165ac..b469af01531 100644
--- a/src/doc/rustc/src/platform-support/windows-gnullvm.md
+++ b/src/doc/rustc/src/platform-support/windows-gnullvm.md
@@ -1,6 +1,6 @@
 # \*-windows-gnullvm
 
-**Tier: 2 (without host tools)**
+**Tier: 2 (with host tools)**
 
 Windows targets similar to `*-windows-gnu` but using UCRT as the runtime and various LLVM tools/libraries instead of GCC/Binutils.
 
diff --git a/src/doc/rustc/src/platform-support/windows-msvc.md b/src/doc/rustc/src/platform-support/windows-msvc.md
new file mode 100644
index 00000000000..71dc4ddc2e6
--- /dev/null
+++ b/src/doc/rustc/src/platform-support/windows-msvc.md
@@ -0,0 +1,69 @@
+# `*-pc-windows-msvc`
+
+Windows MSVC targets.
+
+**Tier 1 with host tools:**
+
+- `i686-pc-windows-msvc`: Windows on 32-bit x86.
+- `x86_64-pc-windows-msvc`: Windows on 64-bit x86.
+
+**Tier 2 with host tools:**
+
+- `aarch64-pc-windows-msvc`: Windows on ARM64.
+
+## Target maintainers
+
+[@ChrisDenton](https://github.com/ChrisDenton)
+[@dpaoliello](https://github.com/dpaoliello)
+[@lambdageek](https://github.com/lambdageek)
+[@sivadeilra](https://github.com/sivadeilra)
+[@wesleywiser](https://github.com/wesleywiser)
+
+## Requirements
+
+### OS version
+
+Windows 10 or higher is required for client installs, Windows Server 2016 or higher is required for server installs.
+
+### Host tooling
+
+The minimum supported Visual Studio version is 2017 but this support is not actively tested in CI.
+It is **highly** recommended to use the latest version of VS (currently VS 2022).
+
+### Platform details
+
+These targets fully implement the Rust standard library.
+
+The `extern "C"` calling convention conforms to Microsoft's default calling convention for the given architecture: [`__cdecl`] on `i686`, [`x64`] on `x86_64` and [`ARM64`] on `aarch64`.
+
+The `*-windows-msvc` targets produce PE/COFF binaries with CodeView debuginfo, the native formats used on Windows.
+
+[`__cdecl`]: https://learn.microsoft.com/en-us/cpp/cpp/cdecl?view=msvc-170
+[`x64`]: https://learn.microsoft.com/en-us/cpp/build/x64-calling-convention?view=msvc-170
+[`ARM64`]: https://learn.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-170
+
+## Building Rust programs
+
+These targets are distributed via `rustup` and can be installed via `rustup component add [--toolchain {name}] {target}`.
+
+For example, adding the 32-bit x86 target to the `nightly` toolchain:
+
+```text
+rustup component add --toolchain nightly i686-pc-windows-msvc
+```
+
+or adding the ARM64 target to the active toolchain:
+
+```text
+rustup component add aarch64-pc-windows-msvc
+```
+
+## Testing
+
+There are no special requirements for testing and running this target.
+
+## Cross-compilation toolchains and C code
+
+Architectural cross-compilation from one Windows host to a different Windows platform is natively supported by the MSVC toolchain provided the appropriate components are selected when using the VS Installer.
+
+Cross-compilation from a non-Windows host to a `*-windows-msvc` target _may_ be possible but is not supported.
diff --git a/src/doc/rustdoc/src/unstable-features.md b/src/doc/rustdoc/src/unstable-features.md
index 69e5a5adbec..27910ad0ab7 100644
--- a/src/doc/rustdoc/src/unstable-features.md
+++ b/src/doc/rustdoc/src/unstable-features.md
@@ -581,7 +581,9 @@ For this rust code:
 
 ```rust
 /// ```
+/// #![allow(dead_code)]
 /// let x = 12;
+/// Ok(())
 /// ```
 pub trait Trait {}
 ```
@@ -590,10 +592,10 @@ The generated output (formatted) will look like this:
 
 ```json
 {
-  "format_version": 1,
+  "format_version": 2,
   "doctests": [
     {
-      "file": "foo.rs",
+      "file": "src/lib.rs",
       "line": 1,
       "doctest_attributes": {
         "original": "",
@@ -609,9 +611,17 @@ The generated output (formatted) will look like this:
         "added_css_classes": [],
         "unknown": []
       },
-      "original_code": "let x = 12;",
-      "doctest_code": "#![allow(unused)]\nfn main() {\nlet x = 12;\n}",
-      "name": "foo.rs - Trait (line 1)"
+      "original_code": "#![allow(dead_code)]\nlet x = 12;\nOk(())",
+      "doctest_code": {
+        "crate_level": "#![allow(unused)]\n#![allow(dead_code)]\n\n",
+        "code": "let x = 12;\nOk(())",
+        "wrapper": {
+          "before": "fn main() { fn _inner() -> core::result::Result<(), impl core::fmt::Debug> {\n",
+          "after": "\n} _inner().unwrap() }",
+          "returns_result": true
+        }
+      },
+      "name": "src/lib.rs - (line 1)"
     }
   ]
 }
@@ -624,6 +634,10 @@ The generated output (formatted) will look like this:
    * `doctest_attributes` contains computed information about the attributes used on the doctests. For more information about doctest attributes, take a look [here](write-documentation/documentation-tests.html#attributes).
    * `original_code` is the code as written in the source code before rustdoc modifies it.
    * `doctest_code` is the code modified by rustdoc that will be run. If there is a fatal syntax error, this field will not be present.
+     * `crate_level` is the crate level code (like attributes or `extern crate`) that will be added at the top-level of the generated doctest.
+     * `code` is "naked" doctest without anything from `crate_level` and `wrapper` content.
+     * `wrapper` contains extra code that will be added before and after `code`.
+       * `returns_result` is a boolean. If `true`, it means that the doctest returns a `Result` type.
    * `name` is the name generated by rustdoc which represents this doctest.
 
 ### html
diff --git a/src/doc/unstable-book/src/compiler-flags/hint-mostly-unused.md b/src/doc/unstable-book/src/compiler-flags/hint-mostly-unused.md
new file mode 100644
index 00000000000..80f5b1c4450
--- /dev/null
+++ b/src/doc/unstable-book/src/compiler-flags/hint-mostly-unused.md
@@ -0,0 +1,33 @@
+# `hint-mostly-unused`
+
+This flag hints to the compiler that most of the crate will probably go unused.
+The compiler can optimize its operation based on this assumption, in order to
+compile faster. This is a hint, and does not guarantee any particular behavior.
+
+This option can substantially speed up compilation if applied to a large
+dependency where the majority of the dependency does not get used. This flag
+may slow down compilation in other cases.
+
+Currently, this option makes the compiler defer as much code generation as
+possible from functions in the crate, until later crates invoke those
+functions. Functions that never get invoked will never have code generated for
+them. For instance, if a crate provides thousands of functions, but only a few
+of them will get called, this flag will result in the compiler only doing code
+generation for the called functions. (This uses the same mechanisms as
+cross-crate inlining of functions.) This does not affect `extern` functions, or
+functions marked as `#[inline(never)]`.
+
+To try applying this flag to one dependency out of a dependency tree, use the
+[`profile-rustflags`](https://doc.rust-lang.org/cargo/reference/unstable.html#profile-rustflags-option)
+feature of nightly cargo:
+
+```toml
+cargo-features = ["profile-rustflags"]
+
+# ...
+[dependencies]
+mostly-unused-dependency = "1.2.3"
+
+[profile.release.package.mostly-unused-dependency]
+rustflags = ["-Zhint-mostly-unused"]
+```
diff --git a/src/doc/unstable-book/src/compiler-flags/macro-stats.md b/src/doc/unstable-book/src/compiler-flags/macro-stats.md
new file mode 100644
index 00000000000..b2622cff057
--- /dev/null
+++ b/src/doc/unstable-book/src/compiler-flags/macro-stats.md
@@ -0,0 +1,24 @@
+# `macro-stats`
+
+This feature is perma-unstable and has no tracking issue.
+
+----
+
+Some macros, especially procedural macros, can generate a surprising amount of
+code, which can slow down compile times. This is hard to detect because the
+generated code is normally invisible to the programmer.
+
+This flag helps identify such cases. When enabled, the compiler measures the
+effect on code size of all used macros and prints a table summarizing that
+effect. For each distinct macro, it counts how many times it is used, and the
+net effect on code size (in terms of lines of code, and bytes of code). The
+code size evaluation uses the compiler's internal pretty-printing, and so will
+be independent of the formatting in the original code.
+
+Note that the net effect of a macro may be negative. E.g. the `cfg!` and
+`#[test]` macros often strip out code.
+
+If a macro is identified as causing a large increase in code size, it is worth
+using `cargo expand` to inspect the post-expansion code, which includes the
+code produced by all macros. It may be possible to optimize the macro to
+produce smaller code, or it may be possible to avoid using it altogether.
diff --git a/src/doc/unstable-book/src/language-features/asm-experimental-arch.md b/src/doc/unstable-book/src/language-features/asm-experimental-arch.md
index d9566c9f55c..121f9493435 100644
--- a/src/doc/unstable-book/src/language-features/asm-experimental-arch.md
+++ b/src/doc/unstable-book/src/language-features/asm-experimental-arch.md
@@ -19,6 +19,7 @@ This feature tracks `asm!` and `global_asm!` support for the following architect
 - M68k
 - CSKY
 - SPARC
+- LoongArch32
 
 ## Register classes
 
@@ -53,6 +54,8 @@ This feature tracks `asm!` and `global_asm!` support for the following architect
 | CSKY         | `freg`         | `f[0-31]`                          | `f`                  |
 | SPARC        | `reg`          | `r[2-29]`                          | `r`                  |
 | SPARC        | `yreg`         | `y`                                | Only clobbers        |
+| LoongArch32  | `reg`          | `$r1`, `$r[4-20]`, `$r[23,30]`     | `r`                  |
+| LoongArch32  | `freg`         | `$f[0-31]`                         | `f`                  |
 
 > **Notes**:
 > - NVPTX doesn't have a fixed register set, so named registers are not supported.
@@ -91,6 +94,8 @@ This feature tracks `asm!` and `global_asm!` support for the following architect
 | CSKY         | `freg`                          | None           | `f32`,                                  |
 | SPARC        | `reg`                           | None           | `i8`, `i16`, `i32`, `i64` (SPARC64 only) |
 | SPARC        | `yreg`                          | N/A            | Only clobbers                           |
+| LoongArch32  | `reg`                           | None           | `i8`, `i16`, `i32`, `f32`               |
+| LoongArch32  | `freg`                          | None           | `f32`, `f64`                            |
 
 ## Register aliases
 
diff --git a/src/doc/unstable-book/src/language-features/unsized-locals.md b/src/doc/unstable-book/src/language-features/unsized-locals.md
deleted file mode 100644
index d5b01a3d616..00000000000
--- a/src/doc/unstable-book/src/language-features/unsized-locals.md
+++ /dev/null
@@ -1,175 +0,0 @@
-# `unsized_locals`
-
-The tracking issue for this feature is: [#48055]
-
-[#48055]: https://github.com/rust-lang/rust/issues/48055
-
-------------------------
-
-This implements [RFC1909]. When turned on, you can have unsized arguments and locals:
-
-[RFC1909]: https://github.com/rust-lang/rfcs/blob/master/text/1909-unsized-rvalues.md
-
-```rust
-#![allow(incomplete_features)]
-#![feature(unsized_locals, unsized_fn_params)]
-
-use std::any::Any;
-
-fn main() {
-    let x: Box<dyn Any> = Box::new(42);
-    let x: dyn Any = *x;
-    //  ^ unsized local variable
-    //               ^^ unsized temporary
-    foo(x);
-}
-
-fn foo(_: dyn Any) {}
-//     ^^^^^^ unsized argument
-```
-
-The RFC still forbids the following unsized expressions:
-
-```rust,compile_fail
-#![feature(unsized_locals)]
-
-use std::any::Any;
-
-struct MyStruct<T: ?Sized> {
-    content: T,
-}
-
-struct MyTupleStruct<T: ?Sized>(T);
-
-fn answer() -> Box<dyn Any> {
-    Box::new(42)
-}
-
-fn main() {
-    // You CANNOT have unsized statics.
-    static X: dyn Any = *answer();  // ERROR
-    const Y: dyn Any = *answer();  // ERROR
-
-    // You CANNOT have struct initialized unsized.
-    MyStruct { content: *answer() };  // ERROR
-    MyTupleStruct(*answer());  // ERROR
-    (42, *answer());  // ERROR
-
-    // You CANNOT have unsized return types.
-    fn my_function() -> dyn Any { *answer() }  // ERROR
-
-    // You CAN have unsized local variables...
-    let mut x: dyn Any = *answer();  // OK
-    // ...but you CANNOT reassign to them.
-    x = *answer();  // ERROR
-
-    // You CANNOT even initialize them separately.
-    let y: dyn Any;  // OK
-    y = *answer();  // ERROR
-
-    // Not mentioned in the RFC, but by-move captured variables are also Sized.
-    let x: dyn Any = *answer();
-    (move || {  // ERROR
-        let y = x;
-    })();
-
-    // You CAN create a closure with unsized arguments,
-    // but you CANNOT call it.
-    // This is an implementation detail and may be changed in the future.
-    let f = |x: dyn Any| {};
-    f(*answer());  // ERROR
-}
-```
-
-## By-value trait objects
-
-With this feature, you can have by-value `self` arguments without `Self: Sized` bounds.
-
-```rust
-#![feature(unsized_fn_params)]
-
-trait Foo {
-    fn foo(self) {}
-}
-
-impl<T: ?Sized> Foo for T {}
-
-fn main() {
-    let slice: Box<[i32]> = Box::new([1, 2, 3]);
-    <[i32] as Foo>::foo(*slice);
-}
-```
-
-And `Foo` will also be object-safe.
-
-```rust
-#![feature(unsized_fn_params)]
-
-trait Foo {
-    fn foo(self) {}
-}
-
-impl<T: ?Sized> Foo for T {}
-
-fn main () {
-    let slice: Box<dyn Foo> = Box::new([1, 2, 3]);
-    // doesn't compile yet
-    <dyn Foo as Foo>::foo(*slice);
-}
-```
-
-One of the objectives of this feature is to allow `Box<dyn FnOnce>`.
-
-## Variable length arrays
-
-The RFC also describes an extension to the array literal syntax: `[e; dyn n]`. In the syntax, `n` isn't necessarily a constant expression. The array is dynamically allocated on the stack and has the type of `[T]`, instead of `[T; n]`.
-
-```rust,ignore (not-yet-implemented)
-#![feature(unsized_locals)]
-
-fn mergesort<T: Ord>(a: &mut [T]) {
-    let mut tmp = [T; dyn a.len()];
-    // ...
-}
-
-fn main() {
-    let mut a = [3, 1, 5, 6];
-    mergesort(&mut a);
-    assert_eq!(a, [1, 3, 5, 6]);
-}
-```
-
-VLAs are not implemented yet. The syntax isn't final, either. We may need an alternative syntax for Rust 2015 because, in Rust 2015, expressions like `[e; dyn(1)]` would be ambiguous. One possible alternative proposed in the RFC is `[e; n]`: if `n` captures one or more local variables, then it is considered as `[e; dyn n]`.
-
-## Advisory on stack usage
-
-It's advised not to casually use the `#![feature(unsized_locals)]` feature. Typical use-cases are:
-
-- When you need a by-value trait objects.
-- When you really need a fast allocation of small temporary arrays.
-
-Another pitfall is repetitive allocation and temporaries. Currently the compiler simply extends the stack frame every time it encounters an unsized assignment. So for example, the code
-
-```rust
-#![feature(unsized_locals)]
-
-fn main() {
-    let x: Box<[i32]> = Box::new([1, 2, 3, 4, 5]);
-    let _x = {{{{{{{{{{*x}}}}}}}}}};
-}
-```
-
-and the code
-
-```rust
-#![feature(unsized_locals)]
-
-fn main() {
-    for _ in 0..10 {
-        let x: Box<[i32]> = Box::new([1, 2, 3, 4, 5]);
-        let _x = *x;
-    }
-}
-```
-
-will unnecessarily extend the stack frame.