Unwrap all note blocks

This is to follow the style guide (and fix some broken blockquotes).

Author: ehuss

src/attributes.md

@@ -228,8 +228,7 @@ pub fn f() {}
 ```
 
 > [!NOTE]
-> `rustc` currently recognizes the tools "clippy", "rustfmt", "diagnostic",
-> "miri" and "rust_analyzer".
+> `rustc` currently recognizes the tools "clippy", "rustfmt", "diagnostic", "miri" and "rust_analyzer".
 
 r[attributes.builtin]
 ## Built-in attributes index

src/attributes/codegen.md

@@ -27,9 +27,7 @@ should be placed in the caller, rather than generating code to call the
 function where it is defined.
 
 > [!NOTE]
-> The `rustc` compiler automatically inlines functions based on
-> internal heuristics. Incorrectly inlining functions can make the program
-> slower, so this attribute should be used with care.
+> The `rustc` compiler automatically inlines functions based on internal heuristics. Incorrectly inlining functions can make the program slower, so this attribute should be used with care.
 
 r[attributes.codegen.inline.modes]
 There are three ways to use the inline attribute:
@@ -41,8 +39,7 @@ There are three ways to use the inline attribute:
   performed.
 
 > [!NOTE]
-> `#[inline]` in every form is a hint, with no *requirements*
-> on the language to place a copy of the attributed function in the caller.
+> `#[inline]` in every form is a hint, with no *requirements* on the language to place a copy of the attributed function in the caller.
 
 r[attributes.codegen.cold]
 ### The `cold` attribute
@@ -232,8 +229,7 @@ Reference Manual], or elsewhere on [developer.arm.com].
 [developer.arm.com]: https://developer.arm.com
 
 > [!NOTE]
-> The following pairs of features should both be marked as enabled
-> or disabled together if used:
+> The following pairs of features should both be marked as enabled or disabled together if used:
 > - `paca` and `pacg`, which LLVM currently implements as one feature.
 
 
@@ -394,10 +390,7 @@ See the [`is_x86_feature_detected`] or [`is_aarch64_feature_detected`] macros
 in the standard library for runtime feature detection on these platforms.
 
 > [!NOTE]
-> `rustc` has a default set of features enabled for each target and CPU.
-> The CPU may be chosen with the [`-C target-cpu`] flag. Individual features
-> may be enabled or disabled for an entire crate with the
-> [`-C target-feature`] flag.
+> `rustc` has a default set of features enabled for each target and CPU. The CPU may be chosen with the [`-C target-cpu`] flag. Individual features may be enabled or disabled for an entire crate with the [`-C target-feature`] flag.
 
 r[attributes.codegen.track_caller]
 ## The `track_caller` attribute
@@ -432,12 +425,10 @@ fn f() {
 ```
 
 > [!NOTE]
-> `core` provides [`core::panic::Location::caller`] for observing caller locations. It wraps
-> the [`core::intrinsics::caller_location`] intrinsic implemented by `rustc`.
+> `core` provides [`core::panic::Location::caller`] for observing caller locations. It wraps the [`core::intrinsics::caller_location`] intrinsic implemented by `rustc`.
 
 > [!NOTE]
-> Because the resulting `Location` is a hint, an implementation may halt its walk up the stack
-> early. See [Limitations](#limitations) for important caveats.
+> Because the resulting `Location` is a hint, an implementation may halt its walk up the stack early. See [Limitations](#limitations) for important caveats.
 
 #### Examples
 
@@ -511,12 +502,7 @@ caller information across virtual calls. A common example of this coercion is th
 trait object whose methods are attributed.
 
 > [!NOTE]
-> The aforementioned shim for function pointers is necessary because `rustc` implements
-> `track_caller` in a codegen context by appending an implicit parameter to the function ABI, but
-> this would be unsound for an indirect call because the parameter is not a part of the function's
-> type and a given function pointer type may or may not refer to a function with the attribute. The
-> creation of a shim hides the implicit parameter from callers of the function pointer, preserving
-> soundness.
+> The aforementioned shim for function pointers is necessary because `rustc` implements `track_caller` in a codegen context by appending an implicit parameter to the function ABI, but this would be unsound for an indirect call because the parameter is not a part of the function's type and a given function pointer type may or may not refer to a function with the attribute. The creation of a shim hides the implicit parameter from callers of the function pointer, preserving soundness.
 
 [_MetaListNameValueStr_]: ../attributes.md#meta-item-attribute-syntax
 [`-C target-cpu`]: ../../rustc/codegen-options/index.html#target-cpu

src/attributes/diagnostics.md

@@ -38,8 +38,7 @@ r[attributes.diagnostics.lint.forbid]
    level afterwards,
 
 > [!NOTE]
-> The lint checks supported by `rustc` can be found via `rustc -W help`,
-> along with their default settings and are documented in the [rustc book].
+> The lint checks supported by `rustc` can be found via `rustc -W help`, along with their default settings and are documented in the [rustc book].
 
 ```rust
 pub mod m1 {
@@ -100,9 +99,7 @@ pub mod m3 {
 ```
 
 > [!NOTE]
-> `rustc` allows setting lint levels on the
-> [command-line][rustc-lint-cli], and also supports [setting
-> caps][rustc-lint-caps] on the lints that are reported.
+> `rustc` allows setting lint levels on the [command-line][rustc-lint-cli], and also supports [setting caps][rustc-lint-caps] on the lints that are reported.
 
 r[attributes.diagnostics.lint.reason]
 ### Lint Reasons
@@ -225,8 +222,7 @@ pub fn another_example() {
 ```
 
 > [!NOTE]
-> The behavior of `#[expect(unfulfilled_lint_expectations)]` is currently
-> defined to always generate the `unfulfilled_lint_expectations` lint.
+> The behavior of `#[expect(unfulfilled_lint_expectations)]` is currently defined to always generate the `unfulfilled_lint_expectations` lint.
 
 r[attributes.diagnostics.lint.group]
 ### Lint groups
@@ -438,10 +434,7 @@ r[attributes.diagnostics.must_use.trait-impl-function]
 When used on a function in a trait implementation, the attribute does nothing.
 
 > [!NOTE]
-> Trivial no-op expressions containing the value will not violate the
-> lint. Examples include wrapping the value in a type that does not implement
-> [`Drop`] and then not using that type and being the final expression of a
-> [block expression] that is not used.
+> Trivial no-op expressions containing the value will not violate the lint. Examples include wrapping the value in a type that does not implement [`Drop`] and then not using that type and being the final expression of a [block expression] that is not used.
 >
 > ```rust
 > #[must_use]
@@ -458,8 +451,7 @@ When used on a function in a trait implementation, the attribute does nothing.
 > ```
 
 > [!NOTE]
-> It is idiomatic to use a [let statement] with a pattern of `_`
-> when a must-used value is purposely discarded.
+> It is idiomatic to use a [let statement] with a pattern of `_` when a must-used value is purposely discarded.
 >
 > ```rust
 > #[must_use]

src/attributes/testing.md

@@ -27,8 +27,7 @@ Test functions must be free, monomorphic functions that take no arguments, and t
   onwards, also update it in the crates-and-source-files.md file -->
 
 > [!NOTE]
-> The test mode is enabled by passing the `--test` argument to `rustc`
-> or using `cargo test`.
+> The test mode is enabled by passing the `--test` argument to `rustc` or using `cargo test`.
 
 r[attributes.testing.test.success]
 The test harness calls the returned value's [`report`] method, and classifies the test as passed or failed depending on whether the resulting [`ExitCode`] represents successful termination.
@@ -71,8 +70,7 @@ fn mytest() {
 ```
 
 > [!NOTE]
-> The `rustc` test harness supports the `--include-ignored` flag to
-> force ignored tests to be run.
+> The `rustc` test harness supports the `--include-ignored` flag to force ignored tests to be run.
 
 r[attributes.testing.should_panic]
 ## The `should_panic` attribute

src/behavior-considered-undefined.md

@@ -102,11 +102,7 @@ r[undefined.runtime]
   * The runtime assumes that a Rust stack frame is not deallocated without executing destructors for local variables owned by the stack frame. This assumption can be violated by C functions like `longjmp`.
 
 > [!NOTE]
-> Undefined behavior affects the entire program. For example, calling
-> a function in C that exhibits undefined behavior of C means your entire
-> program contains undefined behaviour that can also affect the Rust code. And
-> vice versa, undefined behavior in Rust can cause adverse affects on code
-> executed by any FFI calls to other languages.
+> Undefined behavior affects the entire program. For example, calling a function in C that exhibits undefined behavior of C means your entire program contains undefined behaviour that can also affect the Rust code. And vice versa, undefined behavior in Rust can cause adverse affects on code executed by any FFI calls to other languages.
 
 r[undefined.pointed-to]
 ### Pointed-to bytes
@@ -239,8 +235,7 @@ r[undefined.validity.valid-range]
   In the standard library, this affects [`NonNull<T>`] and [`NonZero<T>`].
 
   > [!NOTE]
-  > `rustc` achieves this with the unstable
-  > `rustc_layout_scalar_valid_range_*` attributes.
+  > `rustc` achieves this with the unstable `rustc_layout_scalar_valid_range_*` attributes.
 
 r[undefined.validity.undef]
 **Note:** Uninitialized memory is also implicitly invalid for any type that has

src/comments.md

@@ -72,11 +72,7 @@ r[comments.doc.bare-crs]
 The character `U+000D` (CR) is not allowed in doc comments.
 
 > [!NOTE]
-> It is conventional for doc comments to contain Markdown, as expected by
-> `rustdoc`. However, the comment syntax does not respect any internal Markdown.
-> ``/** `glob = "*/*.rs";` */`` terminates the comment at the first `*/`, and the
-> remaining code would cause a syntax error. This slightly limits the content of
-> block doc comments compared to line doc comments.
+> It is conventional for doc comments to contain Markdown, as expected by `rustdoc`. However, the comment syntax does not respect any internal Markdown. ``/** `glob = "*/*.rs";` */`` terminates the comment at the first `*/`, and the remaining code would cause a syntax error. This slightly limits the content of block doc comments compared to line doc comments.
 
 > [!NOTE]
 > The sequence `U+000D` (CR) immediately followed by `U+000A` (LF) would have been previously transformed into a single `U+000A` (LF).

src/conditional-compilation.md

@@ -82,13 +82,10 @@ It is not possible to set a
 configuration option from within the source code of the crate being compiled.
 
 > [!NOTE]
-> For `rustc`, arbitrary-set configuration options are set using the
-> [`--cfg`] flag. Configuration values for a specified target can be displayed with `rustc --print cfg --target $TARGET`.
+> For `rustc`, arbitrary-set configuration options are set using the [`--cfg`] flag. Configuration values for a specified target can be displayed with `rustc --print cfg --target $TARGET`.
 
 > [!NOTE]
-> Configuration options with the key `feature` are a convention used
-> by [Cargo][cargo-feature] for specifying compile-time options and optional
-> dependencies.
+> Configuration options with the key `feature` are a convention used by [Cargo][cargo-feature] for specifying compile-time options and optional dependencies.
 
 r[cfg.target_arch]
 ### `target_arch`
@@ -426,10 +423,7 @@ fn bewitched() {}
 ```
 
 > [!NOTE]
-> The `cfg_attr` can expand to another `cfg_attr`. For example,
-> `#[cfg_attr(target_os = "linux", cfg_attr(feature = "multithreaded", some_other_attribute))]`
-> is valid. This example would be equivalent to
-> `#[cfg_attr(all(target_os = "linux", feature ="multithreaded"), some_other_attribute)]`.
+> The `cfg_attr` can expand to another `cfg_attr`. For example, `#[cfg_attr(target_os = "linux", cfg_attr(feature = "multithreaded", some_other_attribute))]` is valid. This example would be equivalent to `#[cfg_attr(all(target_os = "linux", feature ="multithreaded"), some_other_attribute)]`.
 
 r[cfg.cfg_attr.restriction]
 The `cfg_attr` attribute is allowed anywhere attributes are allowed.

src/crates-and-source-files.md

@@ -8,10 +8,7 @@ r[crate.syntax]
 > &nbsp;&nbsp; [_Item_]<sup>\*</sup>
 
 > [!NOTE]
-> Although Rust, like any other language, can be implemented by an
-> interpreter as well as a compiler, the only existing implementation is a
-> compiler, and the language has always been designed to be compiled. For these
-> reasons, this section assumes a compiler.
+> Although Rust, like any other language, can be implemented by an interpreter as well as a compiler, the only existing implementation is a compiler, and the language has always been designed to be compiled. For these reasons, this section assumes a compiler.
 
 r[crate.compile-time]
 Rust's semantics obey a *phase distinction* between compile-time and

src/destructors.md

@@ -212,10 +212,7 @@ smallest scope that contains the expression and is one of the following:
 * The entirety of the tail expression of a block ([destructors.scope.temporary.edition2024]).
 
 > [!NOTE]
-> The [scrutinee] of a `match` expression is not a temporary scope, so
-> temporaries in the scrutinee can be dropped after the `match` expression. For
-> example, the temporary for `1` in `match 1 { ref mut z => z };` lives until
-> the end of the statement.
+> The [scrutinee] of a `match` expression is not a temporary scope, so temporaries in the scrutinee can be dropped after the `match` expression. For example, the temporary for `1` in `match 1 { ref mut z => z };` lives until the end of the statement.
 
 r[destructors.scope.temporary.edition2024]
 > **Edition differences**: The 2024 edition added two new temporary scope narrowing rules: `if let` temporaries are dropped before the `else` block, and temporaries of tail expressions of blocks are dropped immediately after the tail expression is evaluated.
@@ -315,8 +312,7 @@ r[destructors.scope.lifetime-extension]
 
 
 > [!NOTE]
-> The exact rules for temporary lifetime extension are subject to
-> change. This is describing the current behavior only.
+> The exact rules for temporary lifetime extension are subject to change. This is describing the current behavior only.
 
 r[destructors.scope.lifetime-extension.let]
 The temporary scopes for expressions in `let` statements are sometimes
@@ -433,8 +429,7 @@ and [`std::mem::ManuallyDrop`] provides a wrapper to prevent a
 variable or field from being dropped automatically.
 
 > [!NOTE]
-> Preventing a destructor from being run via [`std::mem::forget`] or other means is safe even if it has a type that isn't `'static`.
-> Besides the places where destructors are guaranteed to run as defined by this document, types may *not* safely rely on a destructor being run for soundness.
+> Preventing a destructor from being run via [`std::mem::forget`] or other means is safe even if it has a type that isn't `'static`. Besides the places where destructors are guaranteed to run as defined by this document, types may *not* safely rely on a destructor being run for soundness.
 
 r[destructors.process-termination]
 ### Process termination without unwinding

src/dynamically-sized-types.md

@@ -35,8 +35,7 @@ r[dynamic-sized.struct-field]
   <abbr title="dynamically sized type">DST</abbr>.
 
 > [!NOTE]
-> [Variables], function parameters, [const] items, and [static] items must be
-`Sized`.
+> [Variables], function parameters, [const] items, and [static] items must be `Sized`.
 
 [sized]: special-types-and-traits.md#sized
 [Slices]: types/slice.md

src/expressions.md

@@ -128,8 +128,7 @@ The operands of these expressions are evaluated prior to applying the effects of
 Expressions taking multiple operands are evaluated left to right as written in the source code.
 
 > [!NOTE]
-> Which subexpressions are the operands of an expression is
-> determined by expression precedence as per the previous section.
+> Which subexpressions are the operands of an expression is determined by expression precedence as per the previous section.
 
 For example, the two `next` method calls will always be called in the same order:
 

src/expressions/block-expr.md

@@ -66,8 +66,7 @@ r[expr.block.value]
 Blocks are always [value expressions] and evaluate the last operand in value expression context.
 
 > [!NOTE]
-> This can be used to force moving a value if really needed.
-> For example, the following example fails on the call to `consume_self` because the struct was moved out of `s` in the block expression.
+> This can be used to force moving a value if really needed. For example, the following example fails on the call to `consume_self` because the struct was moved out of `s` in the block expression.
 >
 > ```rust,compile_fail
 > struct Struct;

src/expressions/call-expr.md

@@ -45,9 +45,7 @@ r[expr.call.desugar.ambiguity]
 Function calls may need to be fully qualified, depending on the ambiguity of a call in light of in-scope items.
 
 > [!NOTE]
-> In the past, the terms "Unambiguous Function Call Syntax", "Universal Function Call Syntax", or "UFCS", have been used in documentation, issues, RFCs, and other community writings.
-> However, these terms lack descriptive power and potentially confuse the issue at hand.
-> We mention them here for searchability's sake.
+> In the past, the terms "Unambiguous Function Call Syntax", "Universal Function Call Syntax", or "UFCS", have been used in documentation, issues, RFCs, and other community writings. However, these terms lack descriptive power and potentially confuse the issue at hand. We mention them here for searchability's sake.
 
 r[expr.call.desugar.limits]
 Several situations often occur which result in ambiguities about the receiver or referent of method or associated function calls.