Fix header rules

src/attributes/codegen.md

@@ -1,7 +1,6 @@
 r[attributes.codegen]
 # Code generation attributes
 
-
 The following [attributes] are used for controlling code generation.
 
 r[attributes.codegen.hint]
@@ -44,14 +43,12 @@ There are three ways to use the inline attribute:
 r[attributes.codegen.cold]
 ### The `cold` attribute
 
-
 The *`cold` [attribute]* suggests that the attributed function is unlikely to
 be called.
 
 r[attributes.codegen.no_builtins]
 ## The `no_builtins` attribute
 
-
 The *`no_builtins` [attribute]* may be applied at the crate level to disable
 optimizing certain code patterns to invocations of library functions that are
 assumed to exist.
@@ -143,13 +140,11 @@ be used with a `target_feature` attribute.
 r[attributes.codegen.target_feature.availability]
 ### Available features
 
-
 The following is a list of the available feature names.
 
 r[attributes.codegen.target_feature.x86]
 #### `x86` or `x86_64`
 
-
 Executing code with unsupported features is undefined behavior on this platform.
 Hence on this platform usage of `#[target_feature]` functions follows the
 [above restrictions][attributes.codegen.target_feature.safety-restrictions].
@@ -218,7 +213,6 @@ Feature     | Implicitly Enables | Description
 r[attributes.codegen.target_feature.aarch64]
 #### `aarch64`
 
-
 On this platform the usage of `#[target_feature]` functions follows the
 [above restrictions][attributes.codegen.target_feature.safety-restrictions].
 
@@ -232,7 +226,6 @@ Reference Manual], or elsewhere on [developer.arm.com].
 > 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.
 
-
 Feature        | Implicitly Enables | Feature Name
 ---------------|--------------------|-------------------
 `aes`          | `neon`         | FEAT_AES & FEAT_PMULL --- Advanced <abbr title="Single Instruction Multiple Data">SIMD</abbr> AES & PMULL instructions
@@ -283,7 +276,6 @@ Feature        | Implicitly Enables | Feature Name
 r[attributes.codegen.target_feature.riscv]
 #### `riscv32` or `riscv64`
 
-
 On this platform the usage of `#[target_feature]` functions follows the
 [above restrictions][attributes.codegen.target_feature.safety-restrictions].
 
@@ -345,7 +337,6 @@ Feature     | Implicitly Enables  | Description
 r[attributes.codegen.target_feature.wasm]
 #### `wasm32` or `wasm64`
 
-
 Safe `#[target_feature]` functions may always be used in safe contexts on Wasm
 platforms. It is impossible to cause undefined behavior via the
 `#[target_feature]` attribute because attempting to use instructions
@@ -539,7 +530,6 @@ It is a compilation error to use the `instruction_set` attribute on a target tha
 r[attributes.codegen.instruction_set.arm]
 ### On ARM
 
-
 For the `ARMv4T` and `ARMv5te` architectures, the following are supported:
 * `arm::a32` --- Generate the function as A32 "ARM" code.
 * `arm::t32` --- Generate the function as T32 "Thumb" code.

src/attributes/debugger.md

@@ -1,7 +1,6 @@
 r[attributes.debugger]
 # Debugger attributes
 
-
 The following [attributes] are used for enhancing the debugging experience when using third-party debuggers like GDB or WinDbg.
 
 r[attributes.debugger.debugger_visualizer]

src/attributes/diagnostics.md

@@ -549,9 +549,8 @@ error[E0277]: My Message for `ImportantTrait<i32>` implemented for `String`
    = note: Note 2
 ```
 
-### The `diagnostic::do_not_recommend` attribute
-
 r[attributes.diagnostic.do_not_recommend]
+### The `diagnostic::do_not_recommend` attribute
 
 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.

src/attributes/limits.md

@@ -1,7 +1,6 @@
 r[attributes.limits]
 # Limits
 
-
 The following [attributes] affect compile-time limits.
 
 r[attributes.limits.recursion_limit]
@@ -44,7 +43,6 @@ a!{}
 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.
 >

src/attributes/testing.md

@@ -1,7 +1,6 @@
 r[attributes.testing]
 # Testing attributes
 
-
 The following [attributes] are used for specifying functions for performing
 tests. Compiling a crate in "test" mode enables building the test functions
 along with a test harness for executing the tests. Enabling the test mode also

src/behavior-considered-undefined.md

@@ -100,11 +100,10 @@ r[undefined.pointed-to]
 
 The span of bytes a pointer or reference "points to" is determined by the pointer value and the size of the pointee type (using `size_of_val`).
 
+r[undefined.misaligned]
 ### Places based on misaligned pointers
 [based on a misaligned pointer]: #places-based-on-misaligned-pointers
 
-r[undefined.misaligned]
-
 r[undefined.misaligned.general]
 A place is said to be "based on a misaligned pointer" if the last `*` projection
 during place computation was performed on a pointer that was not aligned for its
@@ -141,11 +140,10 @@ more aligned than the type that contains it, i.e., `repr(packed)`. This means
 that being based on an aligned pointer is always sufficient to ensure that the
 new reference is aligned, but it is not always necessary.
 
+r[undefined.dangling]
 ### Dangling pointers
 [dangling]: #dangling-pointers
 
-r[undefined.dangling]
-
 r[undefined.dangling.general]
 A reference/pointer is "dangling" if not all of the bytes it
 [points to] are part of the same live allocation (so in particular they all have to be
@@ -164,11 +162,10 @@ In particular, the dynamic size of a Rust value (as determined by `size_of_val`)
 must never exceed `isize::MAX`, since it is impossible for a single allocation
 to be larger than `isize::MAX`.
 
+r[undefined.validity]
 ### Invalid values
 [invalid-values]: #invalid-values
 
-r[undefined.validity]
-
 r[undefined.validity.general]
 The Rust compiler assumes that all values produced during program execution are
 "valid", and producing an invalid value is hence immediate UB.

src/comments.md

@@ -1,7 +1,6 @@
 r[comments.syntax]
 # Comments
 
-
 > **<sup>Lexer</sup>**\
 > LINE_COMMENT :\
 > &nbsp;&nbsp; &nbsp;&nbsp; `//` (~\[`/` `!` `\n`] | `//`) ~`\n`<sup>\*</sup>\
@@ -37,7 +36,6 @@ r[comments.syntax]
 r[comments.normal]
 ## Non-doc comments
 
-
 Comments follow the general C++ style of line (`//`) and
 block (`/* ... */`) comment forms. Nested block comments are supported.
 

src/conditional-compilation.md

@@ -263,7 +263,6 @@ r[cfg.target_has_atomic.stdlib]
 When this cfg is present, all of the stable [`core::sync::atomic`] APIs are available for
 the relevant atomic width.
 
-
 r[cfg.target_has_atomic.values]
 Possible values:
 
@@ -277,14 +276,12 @@ Possible values:
 r[cfg.test]
 ### `test`
 
-
 Enabled when compiling the test harness. Done with `rustc` by using the
 [`--test`] flag. See [Testing] for more on testing support.
 
 r[cfg.debug_assertions]
 ### `debug_assertions`
 
-
 Enabled by default when compiling without optimizations.
 This can be used to enable extra debugging code in development but not in
 production.  For example, it controls the behavior of the standard library's
@@ -293,7 +290,6 @@ production.  For example, it controls the behavior of the standard library's
 r[cfg.proc_macro]
 ### `proc_macro`
 
-
 Set when the crate being compiled is being compiled with the `proc_macro`
 [crate type].
 

src/const_eval.md

@@ -107,11 +107,10 @@ r[const-eval.const-expr.loop]
 r[const-eval.const-expr.if-match]
 * [if], [`if let`] and [match] expressions.
 
+r[const-eval.const-context]
 ## Const context
 [const context]: #const-context
 
-r[const-eval.const-context]
-
 r[const-eval.const-context.general]
 A _const context_ is one of the following:
 

src/destructors.md

@@ -136,7 +136,6 @@ r[destructors.scope.nesting.other]
 r[destructors.scope.params]
 ### Scopes of function parameters
 
-
 All function parameters are in the scope of the entire function body, so are
 dropped last when evaluating the function. Each actual function parameter is
 dropped after any bindings introduced in that parameter's pattern.
@@ -266,7 +265,6 @@ match PrintOnDrop("Matched value in final expression") {
 r[destructors.scope.operands]
 ### Operands
 
-
 Temporaries are also created to hold the result of operands to an expression
 while the other operands are evaluated. The temporaries are associated to the
 scope of the expression with that operand. Since the temporaries are moved from
@@ -298,7 +296,6 @@ loop {
 r[destructors.scope.const-promotion]
 ### Constant promotion
 
-
 Promotion of a value expression to a `'static` slot occurs when the expression
 could be written in a constant and borrowed, and that borrow could be dereferenced
 where
@@ -311,7 +308,6 @@ always has the type `&'static Option<_>`, as it contains nothing disallowed).
 r[destructors.scope.lifetime-extension]
 ### Temporary lifetime extension
 
-
 > [!NOTE]
 > The exact rules for temporary lifetime extension are subject to change. This is describing the current behavior only.
 
@@ -368,7 +364,6 @@ scope of the initializer expression is extended.
 r[destructors.scope.lifetime-extension.exprs]
 #### Extending based on expressions
 
-
 For a let statement with an initializer, an *extending expression* is an
 expression which is one of the following:
 

src/dynamically-sized-types.md

@@ -1,6 +1,5 @@
-# Dynamically Sized Types
-
 r[dynamic-sized]
+# Dynamically Sized Types
 
 r[dynamic-sized.intro]
 Most types have a fixed size that is known at compile time and implement the

src/identifiers.md

@@ -56,7 +56,6 @@ Identifiers are restricted to the ASCII subset of [`XID_Start`] and [`XID_Contin
 r[ident.normalization]
 ## Normalization
 
-
 Identifiers are normalized using Normalization Form C (NFC) as defined in [Unicode Standard Annex #15][UAX15]. Two identifiers are equal if their NFC forms are equal.
 
 [Procedural][proc-macro] and [declarative][mbe] macros receive normalized identifiers in their input.

src/inline-assembly.md

@@ -1473,7 +1473,6 @@ assert_eq!(s, "Hello World!");
 r[asm.target-specific-directives]
 #### Target Specific Directive Support
 
-
 r[asm.target-specific-directives.dwarf-unwinding]
 ##### Dwarf Unwinding
 

src/input-format.md

@@ -18,13 +18,11 @@ It is an error if the file is not valid UTF-8.
 r[input.byte-order-mark]
 ## Byte order mark removal
 
-
 If the first character in the sequence is `U+FEFF` ([BYTE ORDER MARK]), it is removed.
 
 r[input.crlf]
 ## CRLF normalization
 
-
 Each pair of characters `U+000D` (CR) immediately followed by `U+000A` (LF) is replaced by a single `U+000A` (LF).
 
 Other occurrences of the character `U+000D` (CR) are left in place (they are treated as [whitespace]).
@@ -56,7 +54,6 @@ This prevents an [inner attribute] at the start of a source file being removed.
 r[input.tokenization]
 ## Tokenization
 
-
 The resulting sequence of characters is then converted into tokens as described in the remainder of this chapter.
 
 [inner attribute]: attributes.md

src/linkage.md

@@ -1,7 +1,6 @@
 r[link]
 # Linkage
 
-
 > [!NOTE]
 > This section is described more in terms of the compiler than of the language.
 
@@ -251,9 +250,8 @@ a statically linked binary on MSVC you would execute:
 RUSTFLAGS='-C target-feature=+crt-static' cargo build --target x86_64-pc-windows-msvc
 ```
 
-## Mixed Rust and foreign codebases
-
 r[link.foreign-code]
+## Mixed Rust and foreign codebases
 
 r[link.foreign-code.foreign-linkers]
 If you are mixing Rust with foreign code (e.g. C, C++) and wish to make a single

src/macro-ambiguity.md

@@ -1,7 +1,6 @@
 r[macro.ambiguity]
 # Appendix: Macro Follow-Set Ambiguity Formal Specification
 
-
 This page documents the formal specification of the follow rules for [Macros
 By Example]. They were originally specified in [RFC 550], from which the bulk
 of this text is copied, and expanded upon in subsequent RFCs.

src/macros-by-example.md

@@ -87,7 +87,6 @@ instance, the matcher `(())` will match `{()}` but not `{{}}`. The character
 r[macro.decl.transcription.fragment]
 ### Forwarding a matched fragment
 
-
 When forwarding a matched fragment to another macro-by-example, matchers in
 the second macro will see an opaque AST of the fragment type. The second macro
 can't use literal tokens to match the fragments in the matcher, only a

src/names/preludes.md

@@ -35,7 +35,6 @@ Edition | `no_std` not applied        | `no_std` applied
 2021    | [`std::prelude::rust_2021`] | [`core::prelude::rust_2021`]
 2024    | [`std::prelude::rust_2024`] | [`core::prelude::rust_2024`]
 
-
 > [!NOTE]
 > [`std::prelude::rust_2015`] and [`std::prelude::rust_2018`] have the same contents as [`std::prelude::v1`].
 >

src/procedural-macros.md

@@ -69,7 +69,6 @@ with any token, such as through getting a `Span` from another token.
 r[macro.proc.hygiene]
 ### Procedural macro hygiene
 
-
 Procedural macros are *unhygienic*. This means they behave as if the output
 token stream was simply written inline to the code it's next to. This means that
 it's affected by external items and also affects external imports.

src/statements-and-expressions.md

@@ -1,7 +1,6 @@
 r[stmt-expr]
 # Statements and expressions
 
-
 Rust is _primarily_ an expression language.
 This means that most forms of value-producing or effect-causing evaluation are directed by the uniform syntax category of _expressions_.
 Each kind of expression can typically _nest_ within each other kind of expression, and rules for evaluation of expressions involve specifying both the value produced by the expression and the order in which its sub-expressions are themselves evaluated.

src/statements.md

@@ -19,7 +19,6 @@ Rust has two kinds of statement: [declaration statements](#declaration-statement
 r[statement.decl]
 ## Declaration statements
 
-
 A *declaration statement* is one that introduces one or more *names* into the enclosing statement block.
 The declared names may denote new variables or new [items][item].
 
@@ -147,7 +146,6 @@ if true {
 r[statement.attribute]
 ## Attributes on Statements
 
-
 Statements accept [outer attributes].
 The attributes that have meaning on a statement are [`cfg`], and [the lint check attributes].
 

src/tokens.md

@@ -491,7 +491,6 @@ c"\\x52"; cr"\x52";                  // \x52
 r[lex.token.literal.num]
 ### Number literals
 
-
 A _number literal_ is either an _integer literal_ or a _floating-point
 literal_. The grammar for recognizing the two kinds of literals is mixed.
 
@@ -584,7 +583,6 @@ Examples of integer literals which are accepted as literal expressions:
 
 Note that `-1i8`, for example, is analyzed as two tokens: `-` followed by `1i8`.
 
-
 Examples of integer literals which are not accepted as literal expressions:
 
 ```rust
@@ -687,7 +685,6 @@ Examples of floating-point literals which are not accepted as literal expression
 r[lex.token.literal.reserved]
 #### Reserved forms similar to number literals
 
-
 > **<sup>Lexer</sup>**\
 > RESERVED_NUMBER :\
 > &nbsp;&nbsp; &nbsp;&nbsp; BIN_LITERAL \[`2`-`9`&ZeroWidthSpace;]\
@@ -836,7 +833,6 @@ usages and meanings are defined in the linked pages.
 r[lex.token.delim]
 ## Delimiters
 
-
 Bracket punctuation is used in various parts of the grammar. An open bracket
 must always be paired with a close bracket. Brackets and the tokens within
 them are referred to as "token trees" in [macros].  The three types of brackets are:

src/trait-bounds.md

@@ -120,7 +120,6 @@ Trait and lifetime bounds are also used to name [trait objects].
 r[bound.sized]
 ## `?Sized`
 
-
 `?` is only used to relax the implicit [`Sized`] trait bound for [type parameters] or [associated types].
 `?Sized` may not be used as a bound for other types.
 
@@ -270,7 +269,6 @@ impl<'a, T> Trait<'a, T> for &'a T {}
 r[bound.use]
 ## Use bounds
 
-
 Certain bounds lists may include a `use<..>` bound to control which generic parameters are captured by the `impl Trait` [abstract return type].  See [precise capturing] for more details.
 
 [IDENTIFIER]: identifiers.html

src/type-layout.md

@@ -94,15 +94,13 @@ at least equal to the size and alignment of a pointer.
 r[layout.array]
 ## Array Layout
 
-
 An array of `[T; N]` has a size of `size_of::<T>() * N` and the same alignment
 of `T`. Arrays are laid out so that the zero-based `nth` element of the array
 is offset from the start of the array by `n * size_of::<T>()` bytes.
 
 r[layout.slice]
 ## Slice Layout
 
-
 Slices have the same layout as the section of the array they slice.
 
 > [!NOTE]
@@ -111,7 +109,6 @@ Slices have the same layout as the section of the array they slice.
 r[layout.str]
 ## `str` Layout
 
-
 String slices are a UTF-8 representation of characters that have the same layout as slices of type `[u8]`.
 
 r[layout.tuple]
@@ -127,7 +124,6 @@ zero-sized type to have a size of 0 and an alignment of 1.
 r[layout.trait-object]
 ## Trait Object Layout
 
-
 Trait objects have the same layout as the value the trait object is of.
 
 > [!NOTE]
@@ -136,7 +132,6 @@ Trait objects have the same layout as the value the trait object is of.
 r[layout.closure]
 ## Closure Layout
 
-
 Closures have no layout guarantees.
 
 r[layout.repr]
@@ -349,7 +344,6 @@ assert_eq!(std::mem::align_of::<SizeRoundedUp>(), 4); // From a
 r[layout.repr.c.enum]
 #### `#[repr(C)]` Field-less Enums
 
-
 For [field-less enums], the `C` representation has the size and alignment of
 the default `enum` size and alignment for the target platform's C ABI.
 
@@ -445,7 +439,6 @@ two primitive representations together is an error.
 r[layout.repr.primitive.enum]
 #### Primitive Representation of Field-less Enums
 
-
 For [field-less enums], primitive representations set the size and alignment to
 be the same as the primitive type of the same name. For example, a field-less
 enum with a `u8` representation can only have discriminants between 0 and 255
@@ -454,7 +447,6 @@ inclusive.
 r[layout.repr.primitive.adt]
 #### Primitive Representation of Enums With Fields
 
-
 The representation of a primitive representation enum is a `repr(C)` union of
 `repr(C)` structs for each variant with a field. The first field of each struct
 in the union is the primitive representation version of the enum with all fields
@@ -510,7 +502,6 @@ struct MyVariantD(MyEnumDiscriminant);
 r[layout.repr.primitive-c]
 #### Combining primitive representations of enums with fields and `#[repr(C)]`
 
-
 For enums with fields, it is also possible to combine `repr(C)` and a
 primitive representation (e.g., `repr(C, u8)`). This modifies the [`repr(C)`] by
 changing the representation of the discriminant enum to the chosen primitive

src/types/closure.md

@@ -577,7 +577,6 @@ The rules for [`Send`] and [`Sync`] match those for normal struct types, while
 [`Clone`] and [`Copy`] behave as if [derived]. For [`Clone`], the order of
 cloning of the captured values is left unspecified.
 
-
 Because captures are often by reference, the following general rules arise:
 
 * A closure is [`Sync`] if all captured values are [`Sync`].

src/types/numeric.md

@@ -26,7 +26,6 @@ Type   | Minimum            | Maximum
 `i64`  | -(2<sup>63</sup>)  | 2<sup>63</sup>-1
 `i128` | -(2<sup>127</sup>) | 2<sup>127</sup>-1
 
-
 r[type.numeric.float]
 ## Floating-point types
 

src/unsafe-keyword.md

@@ -63,7 +63,6 @@ Such a trait must be prefixed with the keyword `unsafe` and can only be implemen
 r[unsafe.impl]
 ## Unsafe trait implementations (`unsafe impl`)
 
-
 When implementing an unsafe trait, the implementation needs to be prefixed with the `unsafe` keyword.
 By writing `unsafe impl`, the programmer states that they have taken care of satisfying the extra safety conditions required by the trait.
 
@@ -76,7 +75,6 @@ Unsafe trait implementations are the logical dual to unsafe traits: where unsafe
 r[unsafe.extern]
 ## Unsafe external blocks (`unsafe extern`)
 
-
 The programmer who declares an [external block] must assure that the signatures of the items contained within are correct. Failing to do so may lead to undefined behavior.  That this obligation has been met is indicated by writing `unsafe extern`.
 
 r[unsafe.extern.edition2024]
@@ -88,7 +86,6 @@ r[unsafe.extern.edition2024]
 r[unsafe.attribute]
 ## Unsafe attributes (`#[unsafe(attr)]`)
 
-
 An [unsafe attribute] is one that has extra safety conditions that must be upheld when using the attribute. The compiler cannot check whether these conditions have been upheld.  To assert that they have been, these attributes must be wrapped in `unsafe(..)`, e.g. `#[unsafe(no_mangle)]`.
 
 [unsafe attribute]: attributes.md