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].