Switch all note blocks to use admonition syntax

This will allow us to maintain consistency, and apply styling.

Author: ehuss

src/attributes.md

@@ -227,7 +227,8 @@ struct S {
 pub fn f() {}
 ```
 
-> Note: `rustc` currently recognizes the tools "clippy", "rustfmt", "diagnostic",
+> [!NOTE]
+> `rustc` currently recognizes the tools "clippy", "rustfmt", "diagnostic",
 > "miri" and "rust_analyzer".
 
 r[attributes.builtin]

src/attributes/codegen.md

@@ -26,7 +26,8 @@ The *`inline` [attribute]* suggests that a copy of the attributed function
 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
+> [!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.
 
@@ -39,7 +40,8 @@ There are three ways to use the inline attribute:
 * `#[inline(never)]` *suggests* that an inline expansion should never be
   performed.
 
-> ***Note***: `#[inline]` in every form is a hint, with no *requirements*
+> [!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.
 
 r[attributes.codegen.cold]
@@ -229,7 +231,8 @@ Reference Manual], or elsewhere on [developer.arm.com].
 [ARM Architecture Reference Manual]: https://developer.arm.com/documentation/ddi0487/latest
 [developer.arm.com]: https://developer.arm.com
 
-> ***Note***: The following pairs of features should both be marked as enabled
+> [!NOTE]
+> 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.
 
@@ -390,7 +393,8 @@ r[attributes.codegen.target_feature.remark-rt]
 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.
+> [!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.
@@ -427,10 +431,12 @@ fn f() {
 }
 ```
 
-> Note: `core` provides [`core::panic::Location::caller`] for observing caller locations. It wraps
+> [!NOTE]
+> `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
+> [!NOTE]
+> Because the resulting `Location` is a hint, an implementation may halt its walk up the stack
 > early. See [Limitations](#limitations) for important caveats.
 
 #### Examples
@@ -504,7 +510,8 @@ appears to observers to have been called at the attributed function's definition
 caller information across virtual calls. A common example of this coercion is the creation of a
 trait object whose methods are attributed.
 
-> Note: The aforementioned shim for function pointers is necessary because `rustc` implements
+> [!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

src/attributes/debugger.md

@@ -173,7 +173,8 @@ r[attributes.debugger.collapse_debuginfo.default]
 The `external` behavior is the default for macros that don't have this attribute, unless they are built-in macros.
 For built-in macros the default is `yes`.
 
-> **Note**: `rustc` has a `-C collapse-macro-debuginfo` CLI option to override both the default collapsing behavior and `#[collapse_debuginfo]` attributes.
+> [!NOTE]
+> `rustc` has a `-C collapse-macro-debuginfo` CLI option to override both the default collapsing behavior and `#[collapse_debuginfo]` attributes.
 
 ```rust
 #[collapse_debuginfo(yes)]

src/attributes/diagnostics.md

@@ -37,7 +37,8 @@ r[attributes.diagnostics.lint.forbid]
 * `#[forbid(C)]` is the same as `deny(C)`, but also forbids changing the lint
    level afterwards,
 
-> Note: The lint checks supported by `rustc` can be found via `rustc -W help`,
+> [!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].
 
 ```rust
@@ -98,7 +99,8 @@ pub mod m3 {
 }
 ```
 
-> Note: `rustc` allows setting lint levels on the
+> [!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.
 
@@ -222,7 +224,8 @@ pub fn another_example() {
 }
 ```
 
-> Note: The behavior of `#[expect(unfulfilled_lint_expectations)]` is currently
+> [!NOTE]
+> The behavior of `#[expect(unfulfilled_lint_expectations)]` is currently
 > defined to always generate the `unfulfilled_lint_expectations` lint.
 
 r[attributes.diagnostics.lint.group]
@@ -297,7 +300,8 @@ fn foo() {
 }
 ```
 
-> Note: `rustc` currently recognizes the tool lints for "[clippy]" and "[rustdoc]".
+> [!NOTE]
+> `rustc` currently recognizes the tool lints for "[clippy]" and "[rustdoc]".
 
 r[attributes.diagnostics.deprecated]
 ## The `deprecated` attribute
@@ -433,7 +437,8 @@ impl Trait for i32 {
 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
+> [!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.
@@ -452,7 +457,8 @@ 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 `_`
+> [!NOTE]
+> It is idiomatic to use a [let statement] with a pattern of `_`
 > when a must-used value is purposely discarded.
 >
 > ```rust
@@ -558,7 +564,8 @@ r[attributes.diagnostic.do_not_recommend]
 r[attributes.diagnostic.do_not_recommend.intro]
 The `#[diagnostic::do_not_recommend]` attribute is a hint to the compiler to not show the annotated trait implementation as part of a diagnostic message.
 
-> **Note**: Suppressing the recommendation can be useful if you know that the recommendation would normally not be useful to the programmer. This often occurs with broad, blanket impls. The recommendation may send the programmer down the wrong path, or the trait implementation may be an internal detail that you don't want to expose, or the bounds may not be able to be satisfied by the programmer.
+> [!NOTE]
+> Suppressing the recommendation can be useful if you know that the recommendation would normally not be useful to the programmer. This often occurs with broad, blanket impls. The recommendation may send the programmer down the wrong path, or the trait implementation may be an internal detail that you don't want to expose, or the bounds may not be able to be satisfied by the programmer.
 >
 > For example, in an error message about a type not implementing a required trait, the compiler may find a trait implementation that would satisfy the requirements if it weren't for specific bounds in the trait implementation. The compiler may tell the user that there is an impl, but the problem is the bounds in the trait implementation. The `#[diagnostic::do_not_recommend]` attribute can be used to tell the compiler to *not* tell the user about the trait implementation, and instead simply tell the user the type doesn't implement the required trait.
 

src/attributes/limits.md

@@ -16,7 +16,8 @@ r[attributes.limits.recursion_limit.syntax]
 It uses the [_MetaNameValueStr_]
 syntax to specify the recursion depth.
 
-> Note: The default in `rustc` is 128.
+> [!NOTE]
+> The default in `rustc` is 128.
 
 ```rust,compile_fail
 #![recursion_limit = "4"]
@@ -44,7 +45,8 @@ r[attributes.limits.type_length_limit]
 ## The `type_length_limit` attribute
 
 
-> **Note**: This limit is only enforced when the nightly `-Zenforce-type-length-limit` flag is active.
+> [!NOTE]
+> This limit is only enforced when the nightly `-Zenforce-type-length-limit` flag is active.
 >
 > For more information, see <https://github.com/rust-lang/rust/pull/127670>.
 
@@ -56,7 +58,8 @@ r[attributes.limits.type_length_limit.syntax]
 It is applied at the [crate] level, and uses the [_MetaNameValueStr_] syntax
 to set the limit based on the number of type substitutions.
 
-> Note: The default in `rustc` is 1048576.
+> [!NOTE]
+> The default in `rustc` is 1048576.
 
 ```rust,ignore
 #![type_length_limit = "4"]

src/attributes/testing.md

@@ -26,7 +26,8 @@ Test functions must be free, monomorphic functions that take no arguments, and t
 <!-- If the previous section needs updating (from "must take no arguments"
   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`
+> [!NOTE]
+> The test mode is enabled by passing the `--test` argument to `rustc`
 > or using `cargo test`.
 
 r[attributes.testing.test.success]
@@ -69,7 +70,8 @@ fn mytest() {
 }
 ```
 
-> **Note**: The `rustc` test harness supports the `--include-ignored` flag to
+> [!NOTE]
+> The `rustc` test harness supports the `--include-ignored` flag to
 > force ignored tests to be run.
 
 r[attributes.testing.should_panic]

src/behavior-considered-undefined.md

@@ -101,7 +101,8 @@ r[undefined.runtime]
   * For assumptions specifically related to unwinding, see the [panic documentation][unwinding-ffi].
   * 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
+> [!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
@@ -237,7 +238,8 @@ r[undefined.validity.valid-range]
 * If a type has a custom range of a valid values, then a valid value must be in that range.
   In the standard library, this affects [`NonNull<T>`] and [`NonZero<T>`].
 
-  > **Note**: `rustc` achieves this with the unstable
+  > [!NOTE]
+  > `rustc` achieves this with the unstable
   > `rustc_layout_scalar_valid_range_*` attributes.
 
 r[undefined.validity.undef]

src/comments.md

@@ -71,13 +71,15 @@ modules that occupy a source file.
 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
+> [!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.
 
-> **Note**:  The sequence `U+000D` (CR) immediately followed by `U+000A` (LF) would have been previously transformed into a single `U+000A` (LF).
+> [!NOTE]
+> The sequence `U+000D` (CR) immediately followed by `U+000A` (LF) would have been previously transformed into a single `U+000A` (LF).
 
 ## Examples
 

src/conditional-compilation.md

@@ -58,7 +58,8 @@ Names are written as a single identifier, such as `unix`.
 r[cfg.option-key-value]
 Key-value pairs are written as an identifier, `=`, and then a string, such as `target_arch = "x86_64"`.
 
-> **Note**: Whitespace around the `=` is ignored, so `foo="bar"` and `foo = "bar"` are equivalent.
+> [!NOTE]
+> Whitespace around the `=` is ignored, so `foo="bar"` and `foo = "bar"` are equivalent.
 
 r[cfg.option-key-uniqueness]
 Keys do not need to be unique. For example, both `feature = "std"` and `feature = "serde"` can be set at the same time.
@@ -80,10 +81,12 @@ r[cfg.options.crate]
 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
+> [!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`.
 
-> **Note**: Configuration options with the key `feature` are a convention used
+> [!NOTE]
+> Configuration options with the key `feature` are a convention used
 > by [Cargo][cargo-feature] for specifying compile-time options and optional
 > dependencies.
 
@@ -422,7 +425,8 @@ fn bewitched() {}
 fn bewitched() {}
 ```
 
-> **Note**: The `cfg_attr` can expand to another `cfg_attr`. For example,
+> [!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)]`.

src/crates-and-source-files.md

@@ -7,7 +7,8 @@ r[crate.syntax]
 > &nbsp;&nbsp; [_InnerAttribute_]<sup>\*</sup>\
 > &nbsp;&nbsp; [_Item_]<sup>\*</sup>
 
-> Note: Although Rust, like any other language, can be implemented by an
+> [!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.
@@ -60,7 +61,8 @@ r[crate.attributes]
 The anonymous crate module can have additional attributes that
 apply to the crate as a whole.
 
-> **Note**: The file's contents may be preceded by a [shebang].
+> [!NOTE]
+> The file's contents may be preceded by a [shebang].
 
 ```rust
 // Specify the crate name.
@@ -111,7 +113,8 @@ mod foo {
 use foo::bar as main;
 ```
 
-> **Note**: Types with implementations of [`Termination`] in the standard library include:
+> [!NOTE]
+> Types with implementations of [`Termination`] in the standard library include:
 >
 > * `()`
 > * [`!`]

src/destructors.md

@@ -211,8 +211,7 @@ smallest scope that contains the expression and is one of the following:
 * The pattern-matching condition and consequent body of [`if let`] ([destructors.scope.temporary.edition2024]).
 * The entirety of the tail expression of a block ([destructors.scope.temporary.edition2024]).
 
-> **Notes**:
->
+> [!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
@@ -315,7 +314,8 @@ r[destructors.scope.lifetime-extension]
 ### Temporary lifetime extension
 
 
-> **Note**: The exact rules for temporary lifetime extension are subject to
+> [!NOTE]
+> The exact rules for temporary lifetime extension are subject to
 > change. This is describing the current behavior only.
 
 r[destructors.scope.lifetime-extension.let]
@@ -432,7 +432,8 @@ r[destructors.manually-suppressing]
 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`.
+> [!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.
 
 r[destructors.process-termination]

src/dynamically-sized-types.md

@@ -34,13 +34,14 @@ r[dynamic-sized.struct-field]
   last field; this makes the struct itself a
   <abbr title="dynamically sized type">DST</abbr>.
 
-> **Note**: [variables], function parameters, [const] items, and [static] items must be
+> [!NOTE]
+> [Variables], function parameters, [const] items, and [static] items must be
 `Sized`.
 
 [sized]: special-types-and-traits.md#sized
 [Slices]: types/slice.md
 [trait objects]: types/trait-object.md
 [Pointer types]: types/pointer.md
-[variables]: variables.md
+[Variables]: variables.md
 [const]: items/constant-items.md
 [static]: items/static-items.md

src/expressions.md

@@ -65,7 +65,8 @@ r[expr.structure]
 In this way, the structure of expressions dictates the structure of execution.
 Blocks are just another kind of expression, so blocks, statements, expressions, and blocks again can recursively nest inside each other to an arbitrary depth.
 
-> **Note**: We give names to the operands of expressions so that we may discuss them, but these names are not stable and may be changed.
+> [!NOTE]
+> We give names to the operands of expressions so that we may discuss them, but these names are not stable and may be changed.
 
 r[expr.precedence]
 ## Expression precedence
@@ -126,7 +127,8 @@ r[expr.operand-order.operands-before-primary]
 The operands of these expressions are evaluated prior to applying the effects of the expression.
 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
+> [!NOTE]
+> 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:
@@ -142,7 +144,8 @@ assert_eq!(
 );
 ```
 
-> **Note**: Since this is applied recursively, these expressions are also evaluated from innermost to outermost, ignoring siblings until there are no inner subexpressions.
+> [!NOTE]
+> Since this is applied recursively, these expressions are also evaluated from innermost to outermost, ignoring siblings until there are no inner subexpressions.
 
 r[expr.place-value]
 ## Place Expressions and Value Expressions
@@ -178,7 +181,8 @@ The following contexts are *place expression* contexts:
   expression.
 * The base of a [functional update] struct expression.
 
-> Note: Historically, place expressions were called *lvalues* and value expressions were called *rvalues*.
+> [!NOTE]
+> Historically, place expressions were called *lvalues* and value expressions were called *rvalues*.
 
 r[expr.place-value.assignee]
 An *assignee expression* is an expression that appears in the left operand of an [assignment][assign] expression.