Merge ref 'eda4fc7733ee' from rust-lang/rust

Pull recent changes from https://github.com/rust-lang/rust via Josh.

Upstream ref: rust-lang/rust@eda4fc7
Filtered ref: rust-lang/stdarch@3f3adc6
Upstream diff: rust-lang/rust@1396514...eda4fc7

This merge was created using https://github.com/rust-lang/josh-sync.

Author: The rustc-josh-sync Cronjob Bot

ci/sembr/src/main.rs

@@ -159,6 +159,9 @@ fn lengthen_lines(content: &str, limit: usize) -> String {
         if in_html_div {
             continue;
         }
+        if line.trim_end().ends_with("<br>") {
+            continue;
+        }
         if ignore(line, in_code_block) || REGEX_SPLIT.is_match(line) {
             continue;
         }

rust-version

@@ -1 +1 @@
-44e34e1ac6d7e69b40856cf1403d3da145319c30
+c78a29473a68f07012904af11c92ecffa68fcc75

src/building/bootstrapping/what-bootstrapping-does.md

@@ -442,6 +442,9 @@ If you're using the flake, make sure to also update it with the following comman
 nix flake update --flake ./src/tools/nix-dev-shell
 ```
 
+The shell creates a command named `x` that runs the `./x.py` script with all dependencies
+set up correctly.
+
 ### Note
 
 Note that when using nix on a not-NixOS distribution, it may be necessary to set

src/building/suggested.md

@@ -275,16 +275,16 @@ Here are some notable ones:
 |----------------|-------------|
 | `rustc_def_path` | Dumps the [`def_path_str`] of an item. |
 | `rustc_dump_def_parents` | Dumps the chain of `DefId` parents of certain definitions. |
+| `rustc_dump_inferred_outlives` | Dumps implied bounds of an item. More precisely, the [`inferred_outlives_of`] an item. |
 | `rustc_dump_item_bounds` | Dumps the [`item_bounds`] of an item. |
+| `rustc_dump_object_lifetime_defaults` | Dumps the [object lifetime defaults] of an item. |
 | `rustc_dump_predicates` | Dumps the [`predicates_of`] an item. |
+| `rustc_dump_variances` | Dumps the [variances] of an item. |
 | `rustc_dump_vtable` | Dumps the vtable layout of an impl, or a type alias of a dyn type. |
 | `rustc_hidden_type_of_opaques` | Dumps the [hidden type of each opaque types][opaq] in the crate. |
 | `rustc_layout` | [See this section](#debugging-type-layouts). |
-| `rustc_object_lifetime_default` | Dumps the [object lifetime defaults] of an item. |
-| `rustc_outlives` | Dumps implied bounds of an item. More precisely, the [`inferred_outlives_of`] an item. |
 | `rustc_regions` | Dumps NLL closure region requirements. |
 | `rustc_symbol_name` | Dumps the mangled & demangled [`symbol_name`] of an item. |
-| `rustc_variances` | Dumps the [variances] of an item. |
 
 Right below you can find elaborate explainers on a selected few.
 

src/compiler-debugging.md

@@ -1,23 +1,21 @@
 # Diagnostic and subdiagnostic structs
-rustc has three diagnostic traits that can be used to create diagnostics:
-`Diagnostic`, `LintDiagnostic`, and `Subdiagnostic`.
+rustc has two diagnostic traits that can be used to create diagnostics:
+`Diagnostic` and `Subdiagnostic`.
 
 For simple diagnostics,
 derived impls can be used, e.g. `#[derive(Diagnostic)]`. They are only suitable for simple diagnostics that
-don't require much logic in deciding whether or not to add additional
-subdiagnostics.
+don't require much logic in deciding whether or not to add additional subdiagnostics.
 
 In cases where diagnostics require more complex or dynamic behavior, such as conditionally adding subdiagnostics,
 customizing the rendering logic, or selecting messages at runtime, you will need to manually implement
-the corresponding trait (`Diagnostic`, `LintDiagnostic`, or `Subdiagnostic`).
+the corresponding trait (`Diagnostic` or `Subdiagnostic`).
 This approach provides greater flexibility and is recommended for diagnostics that go beyond simple, static structures.
 
 Diagnostic can be translated into different languages.
 
-## `#[derive(Diagnostic)]` and `#[derive(LintDiagnostic)]`
+## `#[derive(Diagnostic)]`
 
-Consider the [definition][defn] of the "field already declared" diagnostic
-shown below:
+Consider the [definition][defn] of the "field already declared" diagnostic shown below:
 
 ```rust,ignore
 #[derive(Diagnostic)]
@@ -32,47 +30,47 @@ pub struct FieldAlreadyDeclared {
 }
 ```
 
-`Diagnostic` can only be derived on structs and enums. 
+`Diagnostic` can only be derived on structs and enums.
 Attributes that are placed on the type for structs are placed on each 
-variants for enums (or vice versa). Each `Diagnostic` has to have one
+variants for enums (or vice versa).
+Each `Diagnostic` has to have one
 attribute, `#[diag(...)]`, applied to the struct or each enum variant.
 
 If an error has an error code (e.g. "E0624"), then that can be specified using
-the `code` sub-attribute. Specifying a `code` isn't mandatory, but if you are
+the `code` sub-attribute.
+Specifying a `code` isn't mandatory, but if you are
 porting a diagnostic that uses `Diag` to use `Diagnostic`
 then you should keep the code if there was one.
 
-`#[diag(..)]` must provide a message as the first positional argument. 
-The message is written in English, but might be translated to the locale requested by the user. See
-[translation documentation](./translation.md) to learn more about how
+`#[diag(..)]` must provide a message as the first positional argument.
+The message is written in English, but might be translated to the locale requested by the user.
+See [translation documentation](./translation.md) to learn more about how
 translatable error messages are written and how they are generated.
 
 Every field of the `Diagnostic` which does not have an annotation is
-available in Fluent messages as a variable, like `field_name` in the example
-above. Fields can be annotated `#[skip_arg]` if this is undesired.
+available in Fluent messages as a variable, like `field_name` in the example above.
+Fields can be annotated `#[skip_arg]` if this is undesired.
 
 Using the `#[primary_span]` attribute on a field (that has type `Span`)
-indicates the primary span of the diagnostic which will have the main message
-of the diagnostic.
+indicates the primary span of the diagnostic which will have the main message of the diagnostic.
 
 Diagnostics are more than just their primary message, they often include
-labels, notes, help messages and suggestions, all of which can also be
-specified on a `Diagnostic`.
+labels, notes, help messages and suggestions, all of which can also be specified on a `Diagnostic`.
 
 `#[label]`, `#[help]`, `#[warning]` and `#[note]` can all be applied to fields which have the
-type `Span`. Applying any of these attributes will create the corresponding
-subdiagnostic with that `Span`. These attributes take a diagnostic message as an argument.
+type `Span`.
+Applying any of these attributes will create the corresponding subdiagnostic with that `Span`.
+These attributes take a diagnostic message as an argument.
 
 Other types have special behavior when used in a `Diagnostic` derive:
 
 - Any attribute applied to an `Option<T>` will only emit a
   subdiagnostic if the option is `Some(..)`.
-- Any attribute applied to a `Vec<T>` will be repeated for each element of the
-  vector.
+- Any attribute applied to a `Vec<T>` will be repeated for each element of the vector.
 
 `#[help]`, `#[warning]` and `#[note]` can also be applied to the struct itself, in which case
-they work exactly like when applied to fields except the subdiagnostic won't
-have a `Span`. These attributes can also be applied to fields of type `()` for
+they work exactly like when applied to fields except the subdiagnostic won't have a `Span`.
+These attributes can also be applied to fields of type `()` for
 the same effect, which when combined with the `Option` type can be used to
 represent optional `#[note]`/`#[help]`/`#[warning]` subdiagnostics.
 
@@ -84,8 +82,8 @@ Suggestions can be emitted using one of four field attributes:
 - `#[suggestion_verbose("message", code = "...", applicability = "...")]`
 
 Suggestions must be applied on either a `Span` field or a `(Span,
-MachineApplicability)` field. Similarly to other field attributes, a message
-needs to be provided which will be shown to the user.
+MachineApplicability)` field.
+Similarly to other field attributes, a message needs to be provided which will be shown to the user.
 `code` specifies the code that should be suggested as a
 replacement and is a format string (e.g. `{field_name}` would be replaced by
 the value of the `field_name` field of the struct).
@@ -113,8 +111,8 @@ impl<'a, G: EmissionGuarantee> Diagnostic<'a> for FieldAlreadyDeclared {
 }
 ```
 
-Now that we've defined our diagnostic, how do we [use it][use]? It's quite
-straightforward, just create an instance of the struct and pass it to
+Now that we've defined our diagnostic, how do we [use it][use]?
+It's quite straightforward, just create an instance of the struct and pass it to
 `emit_err` (or `emit_warning`):
 
 ```rust,ignore
@@ -125,9 +123,8 @@ tcx.dcx().emit_err(FieldAlreadyDeclared {
 });
 ```
 
-### Reference for `#[derive(Diagnostic)]` and `#[derive(LintDiagnostic)]`
-`#[derive(Diagnostic)]` and `#[derive(LintDiagnostic)]` support the
-following attributes:
+### Reference for `#[derive(Diagnostic)]`
+`#[derive(Diagnostic)]` supports the following attributes:
 
 - `#[diag("message", code = "...")]`
   - _Applied to struct or enum variant._
@@ -164,32 +161,31 @@ following attributes:
     - Value is the suggestion message that will be shown to the user.
     - See [translation documentation](./translation.md).
   - `code = "..."`/`code("...", ...)` (_Mandatory_)
-    - One or multiple format strings indicating the code to be suggested as a
-      replacement. Multiple values signify multiple possible replacements.
+    - One or multiple format strings indicating the code to be suggested as a replacement.
+      Multiple values signify multiple possible replacements.
   - `applicability = "..."` (_Optional_)
     - String which must be one of `machine-applicable`, `maybe-incorrect`,
       `has-placeholders` or `unspecified`.
 - `#[subdiagnostic]`
-  - _Applied to a type that implements `Subdiagnostic` (from
-    `#[derive(Subdiagnostic)]`)._
+  - _Applied to a type that implements `Subdiagnostic` (from `#[derive(Subdiagnostic)]`)._
   - Adds the subdiagnostic represented by the subdiagnostic struct.
 - `#[primary_span]` (_Optional_)
-  - _Applied to `Span` fields on `Subdiagnostic`s. Not used for `LintDiagnostic`s._
+  - _Applied to `Span` fields on `Subdiagnostic`s.
   - Indicates the primary span of the diagnostic.
 - `#[skip_arg]` (_Optional_)
   - _Applied to any field._
   - Prevents the field from being provided as a diagnostic argument.
 
 ## `#[derive(Subdiagnostic)]`
 It is common in the compiler to write a function that conditionally adds a
-specific subdiagnostic to an error if it is applicable. Oftentimes these
-subdiagnostics could be represented using a diagnostic struct even if the
-overall diagnostic could not. In this circumstance, the `Subdiagnostic`
+specific subdiagnostic to an error if it is applicable.
+Oftentimes these subdiagnostics could be represented using a diagnostic struct even if the
+overall diagnostic could not.
+In this circumstance, the `Subdiagnostic`
 derive can be used to represent a partial diagnostic (e.g a note, label, help or
 suggestion) as a struct.
 
-Consider the [definition][subdiag_defn] of the "expected return type" label
-shown below:
+Consider the [definition][subdiag_defn] of the "expected return type" label shown below:
 
 ```rust
 #[derive(Subdiagnostic)]
@@ -208,10 +204,10 @@ pub enum ExpectedReturnTypeLabel<'tcx> {
 }
 ```
 
-Like `Diagnostic`, `Subdiagnostic` can be derived for structs or
-enums. Attributes that are placed on the type for structs are placed on each
-variants for enums (or vice versa). Each `Subdiagnostic` should have one
-attribute applied to the struct or each variant, one of:
+Like `Diagnostic`, `Subdiagnostic` can be derived for structs or enums.
+Attributes that are placed on the type for structs are placed on each
+variants for enums (or vice versa).
+Each `Subdiagnostic` should have one attribute applied to the struct or each variant, one of:
 
 - `#[label(..)]` for defining a label
 - `#[note(..)]` for defining a note
@@ -224,15 +220,14 @@ See [translation documentation](./translation.md) to learn more about how
 translatable error messages are generated.
 
 Using the `#[primary_span]` attribute on a field (with type `Span`) will denote
-the primary span of the subdiagnostic. A primary span is only necessary for a
-label or suggestion, which can not be spanless.
+the primary span of the subdiagnostic.
+A primary span is only necessary for a label or suggestion, which can not be spanless.
 
 Every field of the type/variant which does not have an annotation is available
-in Fluent messages as a variable. Fields can be annotated `#[skip_arg]` if this
-is undesired.
+in Fluent messages as a variable.
+Fields can be annotated `#[skip_arg]` if this is undesired.
 
-Like `Diagnostic`, `Subdiagnostic` supports `Option<T>` and
-`Vec<T>` fields.
+Like `Diagnostic`, `Subdiagnostic` supports `Option<T>` and `Vec<T>` fields.
 
 Suggestions can be emitted using one of four attributes on the type/variant:
 
@@ -241,8 +236,7 @@ Suggestions can be emitted using one of four attributes on the type/variant:
 - `#[suggestion_short("...", code = "...", applicability = "...")]`
 - `#[suggestion_verbose("...", code = "...", applicability = "...")]`
 
-Suggestions require `#[primary_span]` be set on a field and can have the
-following sub-attributes:
+Suggestions require `#[primary_span]` be set on a field and can have the following sub-attributes:
 
 - The first positional argument specifies the message which will be shown to the user.
 - `code` specifies the code that should be suggested as a replacement and is a
@@ -276,8 +270,7 @@ impl<'tcx> Subdiagnostic for ExpectedReturnTypeLabel<'tcx> {
 
 Once defined, a subdiagnostic can be used by passing it to the `subdiagnostic`
 function ([example][subdiag_use_1] and [example][subdiag_use_2]) on a
-diagnostic or by assigning it to a `#[subdiagnostic]`-annotated field of a
-diagnostic struct.
+diagnostic or by assigning it to a `#[subdiagnostic]`-annotated field of a diagnostic struct.
 
 ### Argument sharing and isolation
 
@@ -310,22 +303,24 @@ Additionally, subdiagnostics can access arguments from the main diagnostic with
 `#[derive(Subdiagnostic)]` supports the following attributes:
 
 - `#[label("message")]`, `#[help("message")]`, `#[warning("message")]` or `#[note("message")]`
-  - _Applied to struct or enum variant. Mutually exclusive with struct/enum variant attributes._
+  - _Applied to struct or enum variant.
+    Mutually exclusive with struct/enum variant attributes._
   - _Mandatory_
   - Defines the type to be representing a label, help or note.
   - Message (_Mandatory_)
     - The diagnostic message that will be shown to the user.
     - See [translation documentation](./translation.md).
 - `#[suggestion{,_hidden,_short,_verbose}("message", code = "...", applicability = "...")]`
-  - _Applied to struct or enum variant. Mutually exclusive with struct/enum variant attributes._
+  - _Applied to struct or enum variant.
+    Mutually exclusive with struct/enum variant attributes._
   - _Mandatory_
   - Defines the type to be representing a suggestion.
   - Message (_Mandatory_)
     - The diagnostic message that will be shown to the user.
     - See [translation documentation](./translation.md).
   - `code = "..."`/`code("...", ...)` (_Mandatory_)
-    - One or multiple format strings indicating the code to be suggested as a
-      replacement. Multiple values signify multiple possible replacements.
+    - One or multiple format strings indicating the code to be suggested as a replacement.
+      Multiple values signify multiple possible replacements.
   - `applicability = "..."` (_Optional_)
     - _Mutually exclusive with `#[applicability]` on a field._
     - Value is the applicability of the suggestion.
@@ -335,7 +330,8 @@ Additionally, subdiagnostics can access arguments from the main diagnostic with
       - `has-placeholders`
       - `unspecified`
 - `#[multipart_suggestion{,_hidden,_short,_verbose}("message", applicability = "...")]`
-  - _Applied to struct or enum variant. Mutually exclusive with struct/enum variant attributes._
+  - _Applied to struct or enum variant.
+    Mutually exclusive with struct/enum variant attributes._
   - _Mandatory_
   - Defines the type to be representing a multipart suggestion.
   - Message (_Mandatory_): see `#[suggestion]`
@@ -348,8 +344,7 @@ to multipart suggestions)
   - _Applied to `Span` fields._
   - Indicates the span to be one part of the multipart suggestion.
   - `code = "..."` (_Mandatory_)
-    - Value is a format string indicating the code to be suggested as a
-      replacement.
+    - Value is a format string indicating the code to be suggested as a replacement.
 - `#[applicability]` (_Optional_; only applicable to (simple and multipart) suggestions)
   - _Applied to `Applicability` fields._
   - Indicates the applicability of the suggestion.