Remove excess blank lines

ehuss · ehuss · commit 3678a65b2871 · 2025-03-27T09:13:36.000-07:00
Most of these snuck in with #1710. As part of the style guide, there shouldn't be double blank lines.
diff --git a/src/attributes/codegen.md b/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.
diff --git a/src/attributes/debugger.md b/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]
diff --git a/src/attributes/limits.md b/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.
 >
diff --git a/src/attributes/testing.md b/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
diff --git a/src/comments.md b/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.
 
diff --git a/src/conditional-compilation.md b/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].
 
diff --git a/src/destructors.md b/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:
 
diff --git a/src/identifiers.md b/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.
diff --git a/src/inline-assembly.md b/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
 
diff --git a/src/input-format.md b/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
diff --git a/src/linkage.md b/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.
 
diff --git a/src/macro-ambiguity.md b/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.
diff --git a/src/macros-by-example.md b/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
diff --git a/src/names/preludes.md b/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`].
 >
diff --git a/src/procedural-macros.md b/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.
diff --git a/src/statements-and-expressions.md b/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.
diff --git a/src/statements.md b/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].
 
diff --git a/src/tokens.md b/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:
diff --git a/src/trait-bounds.md b/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
diff --git a/src/type-layout.md b/src/type-layout.md
diff --git a/src/types/closure.md b/src/types/closure.md
diff --git a/src/types/numeric.md b/src/types/numeric.md
diff --git a/src/unsafe-keyword.md b/src/unsafe-keyword.md
