[pull] master from rust-lang:master

src/abi.md

@@ -2,12 +2,9 @@ r[abi]
 # Application binary interface (ABI)
 
 r[abi.intro]
-This section documents features that affect the ABI of the compiled output of
-a crate.
+This section documents features that affect the ABI of the compiled output of a crate.
 
-See *[extern functions]* for information on specifying the ABI for exporting
-functions. See *[external blocks]* for information on specifying the ABI for
-linking external libraries.
+See *[extern functions]* for information on specifying the ABI for exporting functions. See *[external blocks]* for information on specifying the ABI for linking external libraries.
 
 <!-- template:attributes -->
 r[abi.used]
@@ -68,17 +65,13 @@ r[abi.no_mangle]
 ## The `no_mangle` attribute
 
 r[abi.no_mangle.intro]
-The *`no_mangle` attribute* may be used on any [item] to disable standard
-symbol name mangling. The symbol for the item will be the identifier of the
-item's name.
+The *`no_mangle` attribute* may be used on any [item] to disable standard symbol name mangling. The symbol for the item will be the identifier of the item's name.
 
 r[abi.no_mangle.publicly-exported]
-Additionally, the item will be publicly exported from the produced library or
-object file, similar to the [`used` attribute](#the-used-attribute).
+Additionally, the item will be publicly exported from the produced library or object file, similar to the [`used` attribute](#the-used-attribute).
 
 r[abi.no_mangle.unsafe]
-This attribute is unsafe as an unmangled symbol may collide with another symbol
-with the same name (or with a well-known symbol), leading to undefined behavior.
+This attribute is unsafe as an unmangled symbol may collide with another symbol with the same name (or with a well-known symbol), leading to undefined behavior.
 
 ```rust
 #[unsafe(no_mangle)]
@@ -93,8 +86,7 @@ r[abi.link_section]
 ## The `link_section` attribute
 
 r[abi.link_section.intro]
-The *`link_section` attribute* specifies the section of the object file that a
-[function] or [static]'s content will be placed into.
+The *`link_section` attribute* specifies the section of the object file that a [function] or [static]'s content will be placed into.
 
 r[abi.link_section.syntax]
 The `link_section` attribute uses the [MetaNameValueStr] syntax to specify the section name.
@@ -109,8 +101,7 @@ pub static VAR1: u32 = 1;
 ```
 
 r[abi.link_section.unsafe]
-This attribute is unsafe as it allows users to place data and code into sections
-of memory not expecting them, such as mutable data into read-only areas.
+This attribute is unsafe as it allows users to place data and code into sections of memory not expecting them, such as mutable data into read-only areas.
 
 r[abi.link_section.duplicates]
 Only the first use of `link_section` on an item has effect.
@@ -126,8 +117,7 @@ r[abi.export_name]
 ## The `export_name` attribute
 
 r[abi.export_name.intro]
-The *`export_name` attribute* specifies the name of the symbol that will be
-exported on a [function] or [static].
+The *`export_name` attribute* specifies the name of the symbol that will be exported on a [function] or [static].
 
 r[abi.export_name.syntax]
 The `export_name `attribute uses the [MetaNameValueStr] syntax to specify the symbol name.
@@ -138,9 +128,7 @@ pub fn name_in_rust() { }
 ```
 
 r[abi.export_name.unsafe]
-This attribute is unsafe as a symbol with a custom name may collide with another
-symbol with the same name (or with a well-known symbol), leading to undefined
-behavior.
+This attribute is unsafe as a symbol with a custom name may collide with another symbol with the same name (or with a well-known symbol), leading to undefined behavior.
 
 r[abi.export_name.duplicates]
 Only the first use of `export_name` on an item has effect.

src/behavior-not-considered-unsafe.md

@@ -1,8 +1,6 @@
 # Behavior not considered `unsafe`
 
-The Rust compiler does not consider the following behaviors _unsafe_,
-though a programmer may (should) find them undesirable, unexpected,
-or erroneous.
+The Rust compiler does not consider the following behaviors _unsafe_, though a programmer may (should) find them undesirable, unexpected, or erroneous.
 
 - Deadlocks
 - Leaks of memory and other resources
@@ -11,47 +9,22 @@ or erroneous.
 
 ## Integer overflow
 
-If a program contains arithmetic overflow, the programmer has made an
-error. In the following discussion, we maintain a distinction between
-arithmetic overflow and wrapping arithmetic. The first is erroneous,
-while the second is intentional.
+If a program contains arithmetic overflow, the programmer has made an error. In the following discussion, we maintain a distinction between arithmetic overflow and wrapping arithmetic. The first is erroneous, while the second is intentional.
 
-When the programmer has enabled `debug_assert!` assertions (for
-example, by enabling a non-optimized build), implementations must
-insert dynamic checks that `panic` on overflow. Other kinds of builds
-may result in `panics` or silently wrapped values on overflow, at the
-implementation's discretion.
+When the programmer has enabled `debug_assert!` assertions (for example, by enabling a non-optimized build), implementations must insert dynamic checks that `panic` on overflow. Other kinds of builds may result in `panics` or silently wrapped values on overflow, at the implementation's discretion.
 
-In the case of implicitly-wrapped overflow, implementations must
-provide well-defined (even if still considered erroneous) results by
-using two's complement overflow conventions.
+In the case of implicitly-wrapped overflow, implementations must provide well-defined (even if still considered erroneous) results by using two's complement overflow conventions.
 
-The integral types provide inherent methods to allow programmers
-explicitly to perform wrapping arithmetic. For example,
-`i32::wrapping_add` provides two's complement, wrapping addition.
+The integral types provide inherent methods to allow programmers explicitly to perform wrapping arithmetic. For example, `i32::wrapping_add` provides two's complement, wrapping addition.
 
-The standard library also provides a `Wrapping<T>` newtype which
-ensures all standard arithmetic operations for `T` have wrapping
-semantics.
+The standard library also provides a `Wrapping<T>` newtype which ensures all standard arithmetic operations for `T` have wrapping semantics.
 
-See [RFC 560] for error conditions, rationale, and more details about
-integer overflow.
+See [RFC 560] for error conditions, rationale, and more details about integer overflow.
 
 ## Logic errors
 
-Safe code may impose extra logical constraints that can be checked
-at neither compile-time nor runtime. If a program breaks such
-a constraint, the behavior may be unspecified but will not result in
-undefined behavior. This could include panics, incorrect results,
-aborts, and non-termination. The behavior may also differ between
-runs, builds, or kinds of build.
-
-For example, implementing both `Hash` and `Eq` requires that values
-considered equal have equal hashes. Another example are data structures
-like `BinaryHeap`, `BTreeMap`, `BTreeSet`, `HashMap` and `HashSet`
-which describe constraints on the modification of their keys while
-they are in the data structure. Violating such constraints is not
-considered unsafe, yet the program is considered erroneous and
-its behavior unpredictable.
+Safe code may impose extra logical constraints that can be checked at neither compile-time nor runtime. If a program breaks such a constraint, the behavior may be unspecified but will not result in undefined behavior. This could include panics, incorrect results, aborts, and non-termination. The behavior may also differ between runs, builds, or kinds of build.
+
+For example, implementing both `Hash` and `Eq` requires that values considered equal have equal hashes. Another example are data structures like `BinaryHeap`, `BTreeMap`, `BTreeSet`, `HashMap` and `HashSet` which describe constraints on the modification of their keys while they are in the data structure. Violating such constraints is not considered unsafe, yet the program is considered erroneous and its behavior unpredictable.
 
 [RFC 560]: https://github.com/rust-lang/rfcs/blob/master/text/0560-integer-overflow.md

src/conditional-compilation.md

@@ -256,6 +256,25 @@ Possible values:
 * `"128"`
 * `"ptr"`
 
+r[cfg.target_has_atomic_primitive_alignment]
+### `target_has_atomic_primitive_alignment`
+
+r[cfg.target_has_atomic_primitive_alignment.def]
+Key-value option set for each bit width where the [atomic][core::sync::atomic] type has the same alignment as the corresponding integer type.
+
+> [!NOTE]
+> The alignment is usually the same for a given bit width. However, on some targets such as 32-bit x86, 64-bit atomic types such as [`AtomicI64`][core::sync::atomic::AtomicI64] have an alignment of 8 bytes while `i64` is only aligned to 4 bytes. In this situation, `target_has_atomic_primitive_alignment = "64"` is not set.
+
+r[cfg.target_has_atomic_primitive_alignment.values]
+Possible values:
+
+* `"8"`
+* `"16"`
+* `"32"`
+* `"64"`
+* `"128"`
+* `"ptr"`
+
 r[cfg.test]
 ### `test`
 

src/expressions/if-expr.md

@@ -186,15 +186,20 @@ fn nested() {
 ```
 
 r[expr.if.chains.or]
-If any condition operand is a `let` pattern, then none of the condition operands can be a `||` [lazy boolean operator expression][expr.bool-logic] due to ambiguity and precedence with the `let` scrutinee. If a `||` expression is needed, then parentheses can be used. For example:
-
-```rust
-# let foo = Some(123);
-# let condition1 = true;
-# let condition2 = false;
-// Parentheses are required here.
-if let Some(x) = foo && (condition1 || condition2) { /*...*/ }
-```
+If any condition operand is a `let` pattern, then none of the condition operands can be a `||` [lazy boolean operator expression][expr.bool-logic] due to ambiguity and precedence with the `let` scrutinee.
+
+> [!EXAMPLE]
+> If a `||` expression is needed, then parentheses can be used. For example:
+>
+> ```rust
+> # let foo = Some(123);
+> # let condition1 = true;
+> # let condition2 = false;
+> if let Some(x) = foo
+>     // Parentheses are required here.
+>     && (condition1 || condition2)
+> {}
+> ```
 
 r[expr.if.edition2024]
 > [!EDITION-2024]

src/expressions/match-expr.md

@@ -240,8 +240,9 @@ If any guard condition operand is a `let` pattern, then none of the condition op
 > ```rust
 > # let foo = Some([123]);
 > match foo {
->     // Parentheses are required here.
->     Some(xs) if let [x] = xs && (x < -100 || x > 20) => {}
+>     Some(xs) if let [x] = xs
+>         // Parentheses are required here.
+>         && (x < -100 || x > 20) => {}
 >     _ => {}
 > }
 > ```

src/items/external-blocks.md

@@ -405,6 +405,9 @@ The *`link_name` [attribute][attributes]* may be applied to declarations inside
 r[items.extern.attributes.link_name.syntax]
 The `link_name` attribute uses the [MetaNameValueStr] syntax.
 
+r[items.extern.attributes.link_name.invalid-names]
+The symbol name must not be the empty string or contain any `U+0000` (NUL) bytes.
+
 r[items.extern.attributes.link_name.allowed-positions]
 The `link_name` attribute may only be applied to a function or static item in an `extern` block.