Fix non-leaf rules with bodies

src/attributes/codegen.md

@@ -1,6 +1,7 @@
 r[attributes.codegen]
 # Code generation attributes
 
+r[attributes.codegen.intro]
 The following [attributes] are used for controlling code generation.
 
 <!-- template:attributes -->

src/attributes/debugger.md

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

src/attributes/diagnostics.md

@@ -1,12 +1,14 @@
 r[attributes.diagnostics]
 # Diagnostic attributes
 
+r[attributes.diagnostics.intro]
 The following [attributes] are used for controlling or generating diagnostic
 messages during compilation.
 
 r[attributes.diagnostics.lint]
 ## Lint check attributes
 
+r[attributes.diagnostics.lint.intro]
 A lint check names a potentially undesirable coding pattern, such as
 unreachable code or omitted documentation.
 
@@ -227,9 +229,11 @@ pub fn another_example() {
 r[attributes.diagnostics.lint.group]
 ### Lint groups
 
-Lints may be organized into named groups so that the level of related lints
-can be adjusted together. Using a named group is equivalent to listing out the
-lints within that group.
+r[attributes.diagnostics.lint.group.intro]
+Lints may be organized into named groups so that the level of related lints can be adjusted together.
+
+r[attributes.diagnostics.lint.group.equivalence]
+Using a named group is equivalent to listing out the lints within that group.
 
 ```rust,compile_fail
 // This allows all lints in the "unused" group.
@@ -395,7 +399,7 @@ struct MustUse();
 MustUse(); // ERROR: Unused value that must be used.
 ```
 
-r[attributes.diagnostics.must_use.type.uninhabited]
+r[attributes.diagnostics.must_use.type-uninhabited]
 As an exception to [attributes.diagnostics.must_use.type], the lint does not fire for `Result<(), E>` when `E` is [uninhabited] or for `ControlFlow<B, ()>` when `B` is [uninhabited]. A `#[non_exhaustive]` type from an external crate is not considered uninhabited for this purpose, because it may gain constructors in the future.
 
 ```rust

src/attributes/limits.md

@@ -1,6 +1,7 @@
 r[attributes.limits]
 # Limits
 
+r[attributes.limits.intro]
 The following [attributes] affect compile-time limits.
 
 r[attributes.limits.recursion_limit]

src/attributes/testing.md

@@ -1,6 +1,7 @@
 r[attributes.testing]
 # Testing attributes
 
+r[attributes.testing.intro]
 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/attributes/type_system.md

@@ -1,6 +1,7 @@
 r[attributes.type-system]
 # Type system attributes
 
+r[attributes.type-system.intro]
 The following [attributes] are used for changing how a type can be used.
 
 r[attributes.type-system.non_exhaustive]

src/comments.md

@@ -50,6 +50,7 @@ BLOCK_COMMENT_OR_DOC ->
 r[comments.normal]
 ## Non-doc comments
 
+r[comments.normal.intro]
 Comments follow the general C++ style of line (`//`) and block (`/* ... */`) comment forms. Nested block comments are supported.
 
 r[comments.normal.tokenization]

src/destructors.md

@@ -84,7 +84,7 @@ r[destructors.scope.match-arm]
 * Each arm of a `match` expression
 
 r[destructors.scope.nesting]
-Drop scopes are nested within one another as follows. When multiple scopes are left at once, such as when returning from a function, variables are dropped from the inside outwards.
+Drop scopes are nested within one another as follows:
 
 r[destructors.scope.nesting-function]
 * The entire function scope is the outer most scope.
@@ -113,6 +113,9 @@ r[destructors.scope.nesting-match]
 r[destructors.scope.nesting-other]
 * The parent of all other scopes is the scope of the immediately enclosing expression.
 
+r[destructors.scope.nesting-drop-order]
+When multiple scopes are left at once, such as when returning from a function, variables are dropped from the inside outwards.
+
 r[destructors.scope.params]
 ### Scopes of function parameters
 
@@ -381,6 +384,7 @@ Promotion of a value expression to a `'static` slot occurs when the expression c
 r[destructors.scope.lifetime-extension]
 ### Temporary lifetime extension
 
+r[destructors.scope.lifetime-extension.intro]
 > [!NOTE]
 > The exact rules for temporary lifetime extension are subject to change. This is describing the current behavior only.
 

src/items/external-blocks.md

@@ -215,6 +215,7 @@ Like `"C"` and `"system"`, most platform-specific ABI strings also have a [corre
 r[items.extern.variadic]
 ## Variadic functions
 
+r[items.extern.variadic.syntax]
 Functions within external blocks may be made variadic by specifying `...` as the last parameter. The variadic parameter may be specified with a pattern.
 
 ```rust

src/items/generics.md

@@ -16,13 +16,13 @@ ConstParam ->
     ( `=` ( BlockExpression | IDENTIFIER | `-`?LiteralExpression ) )?
 ```
 
-r[items.generics.syntax.intro]
+r[items.generics.intro]
 [Functions], [type aliases], [structs], [enumerations], [unions], [traits], and [implementations] may be *parameterized* by types, constants, and lifetimes. These parameters are listed in angle <span class="parenthetical">brackets (`<...>`)</span>, usually immediately after the name of the item and before its definition. For implementations, which don't have a name, they come directly after `impl`.
 
-r[items.generics.syntax.decl-order]
+r[items.generics.decl-order]
 The order of generic parameters is restricted to lifetime parameters and then type and const parameters intermixed.
 
-r[items.generics.syntax.duplicate-params]
+r[items.generics.duplicate-params]
 The same parameter name may not be declared more than once in a [GenericParams] list.
 
 Some examples of items with type, const, and lifetime parameters:
@@ -35,7 +35,7 @@ struct InnerArray<T, const N: usize>([T; N]);
 struct EitherOrderWorks<const N: bool, U>(U);
 ```
 
-r[items.generics.syntax.scope]
+r[items.generics.scope]
 Generic parameters are in scope within the item definition where they are declared. They are not in scope for items declared within the body of a function as described in [item declarations]. See [generic parameter scopes] for more details.
 
 r[items.generics.builtin-generic-types]

src/items/implementations.md

@@ -41,7 +41,7 @@ The nominal type is called the _implementing type_ and the associable items are
 r[items.impl.inherent.associated-items]
 Inherent implementations associate the contained items to the implementing type.
 
-r[items.impl.inherent.associated-items.allowed-items]
+r[items.impl.inherent.allowed-items]
 Inherent implementations can contain [associated functions] (including [methods]) and [associated constants].
 
 r[items.impl.inherent.type-alias]

src/items/static-items.md

@@ -33,7 +33,7 @@ All access to a static is safe, but there are a number of restrictions on static
 r[items.static.sync]
 * The type must have the [`Sync`](std::marker::Sync) trait bound to allow thread-safe access.
 
-r[items.static.init.omission]
+r[items.static.init-omission]
 The initializer expression must be omitted in an [external block], and must be provided for free static items.
 
 r[items.static.safety-qualifiers]

src/items/use-declarations.md

@@ -368,6 +368,7 @@ m!(use std as _;);
 r[items.use.restrictions]
 ## Restrictions
 
+r[items.use.restrictions.intro]
 The following rules are restrictions for valid `use` declarations.
 
 r[items.use.restrictions.crate-alias]

src/keywords.md

@@ -1,6 +1,7 @@
 r[lex.keywords]
 # Keywords
 
+r[lex.keywords.intro]
 Rust divides keywords into three categories:
 
 * [strict](#strict-keywords)

src/lifetime-elision.md

@@ -1,6 +1,7 @@
 r[lifetime-elision]
 # Lifetime elision
 
+r[lifetime-elision.intro]
 Rust has rules that allow lifetimes to be elided in various places where the compiler can infer a sensible default choice.
 
 r[lifetime-elision.function]

src/linkage.md

@@ -1,10 +1,10 @@
 r[link]
 # Linkage
 
+r[link.intro]
 > [!NOTE]
 > This section is described more in terms of the compiler than of the language.
 
-r[link.intro]
 The compiler supports various methods to link crates together both statically and dynamically. This section will explore the various methods to link crates together, and more information about native libraries can be found in the [FFI section of the book][ffi].
 
 [ffi]: ../book/ch20-01-unsafe-rust.html#using-extern-functions-to-call-external-code

src/macro-ambiguity.md

@@ -1,6 +1,7 @@
 r[macro.ambiguity]
 # Appendix: Macro follow-set ambiguity formal specification
 
+r[macro.ambiguity.intro]
 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.
 
 r[macro.ambiguity.convention]

src/macros-by-example.md

@@ -245,6 +245,7 @@ mod inner {
 m!(1);
 ```
 
+r[macro.decl.scope.textual.function-local]
 Macros can be declared and used locally inside functions as well, and work similarly:
 
 ```rust

src/memory-model.md

@@ -1,6 +1,7 @@
 r[memory]
 # Memory model
 
+r[memory.intro]
 > [!WARNING]
 > The memory model of Rust is incomplete and not fully decided.
 

src/names/name-resolution.md

@@ -576,7 +576,7 @@ r[names.resolution.type-relative]
 [glob import]: items.use.glob
 [item definitions]: ../items.md
 [macro invocations]: ../macros.md#macro-invocation
-[macro textual scope shadowing]: ../macros-by-example.md#r-macro.decl.scope.textual.shadow
+[macro textual scope shadowing]: macro.decl.scope.textual.shadow-path-based
 [name resolution ambiguities]: #r-names.resolution.expansion.imports.ambiguity
 [namespaces]: ../names/namespaces.md
 [outer scope]: #r-names.resolution.general.scopes

src/names/namespaces.md

@@ -80,6 +80,7 @@ fn example<'Foo>(f: Foo) {
 r[names.namespaces.without]
 ## Named entities without a namespace
 
+r[names.namespaces.without.intro]
 The following entities have explicit names, but the names are not a part of any specific namespace.
 
 ### Fields

src/names/scopes.md

@@ -34,6 +34,7 @@ Similar to items within a module or block,  it is an error to introduce an item
 r[names.scopes.pattern-bindings]
 ## Pattern binding scopes
 
+r[names.scopes.pattern-bindings.intro]
 The scope of a local variable [pattern] binding depends on where it is used:
 
 r[names.scopes.pattern-bindings.let]
@@ -144,6 +145,7 @@ trait SomeTrait<'a, T, const N: usize> {
 r[names.scopes.lifetimes]
 ### Lifetime scopes
 
+r[names.scopes.lifetimes.intro]
 Lifetime parameters are declared in a [GenericParams] list and [higher-ranked trait bounds][hrtb].
 
 r[names.scopes.lifetimes.special]

src/paths.md

@@ -188,6 +188,7 @@ type G = std::boxed::Box<dyn std::ops::FnOnce(isize) -> isize>;
 r[paths.qualifiers]
 ## Path qualifiers
 
+r[paths.qualifiers.intro]
 Paths can be denoted with various leading qualifiers to change the meaning of how it is resolved.
 
 > [!NOTE]

src/patterns.md

@@ -324,7 +324,7 @@ let [ref x] = &[()]; //~ ERROR
 let [ref mut x] = &mut [()]; //~ ERROR
 ```
 
-r[patterns.ident.binding.mode-limitations.edition2024]
+r[patterns.ident.binding.mode-limitations-binding-edition2024]
 > [!EDITION-2024]
 > Before the 2024 edition, bindings could explicitly specify a `ref` or `ref mut` binding mode even when the default binding mode was not "move", and they could specify mutability on such bindings with `mut`. In these editions, specifying `mut` on a binding set the binding mode to "move" regardless of the current default binding mode.
 
@@ -335,7 +335,7 @@ Similarly, a reference pattern may only appear when the default binding mode is
 let [&x] = &[&()]; //~ ERROR
 ```
 
-r[patterns.ident.binding.mode-limitations-reference.edition2024]
+r[patterns.ident.binding.mode-limitations-reference-edition2024]
 > [!EDITION-2024]
 > Before the 2024 edition, reference patterns could appear even when the default binding mode was not "move", and had both the effect of matching against the scrutinee and of causing the default binding mode to be reset to "move".
 

src/runtime.md

@@ -1,6 +1,7 @@
 r[runtime]
 # The Rust runtime
 
+r[runtime.intro]
 This section documents features that define some aspects of the Rust runtime.
 
 <!-- template:attributes -->

src/special-types-and-traits.md

@@ -143,6 +143,7 @@ The [`Termination`] trait indicates the acceptable return types for the [main fu
 r[lang-types.auto-traits]
 ## Auto traits
 
+r[lang-types.auto-traits.intro]
 The [`Send`], [`Sync`], [`Unpin`], [`UnwindSafe`], and [`RefUnwindSafe`] traits are _auto traits_. Auto traits have special properties.
 
 r[lang-types.auto-traits.auto-impl]

src/tokens.md

@@ -38,6 +38,7 @@ Within this documentation's grammar, "simple" tokens are given in [string table
 r[lex.token.literal]
 ## Literals
 
+r[lex.token.literal.intro]
 Literals are tokens used in [literal expressions].
 
 ### Examples

src/type-layout.md

@@ -12,6 +12,7 @@ Note that even types with the same layout can still differ in how they are passe
 r[layout.properties]
 ## Size and alignment
 
+r[layout.properties.intro]
 All values have an alignment and size.
 
 r[layout.properties.align]
@@ -175,7 +176,7 @@ The only data layout guarantees made by this representation are those required f
  1. The offset of a field is divisible by that field's alignment.
  2. The alignment of the type is at least the maximum alignment of its fields.
 
-r[layout.repr.rust.layout.struct]
+r[layout.repr.rust.struct]
 For [structs], it is further guaranteed that the fields do not overlap. That is, the fields can be ordered such that the offset plus the size of any field is less than or equal to the offset of the next field in the ordering. The ordering does not have to be the same as the order in which the fields are specified in the declaration of the type.
 
 Be aware that this guarantee does not imply that the fields have distinct addresses: [zero-sized types] may have the same address as other fields in the same struct.

src/types/boolean.md

@@ -1,11 +1,11 @@
 r[type.bool]
 # Boolean type
 
+r[type.bool.intro]
 ```rust
 let b: bool = true;
 ```
 
-r[type.bool.intro]
 The *boolean type* or *bool* is a primitive data type that can take on one of two values, called *true* and *false*.
 
 r[type.bool.literal]
@@ -41,6 +41,7 @@ Like all primitives, the boolean type [implements][p-impl] the [traits][p-traits
 r[type.bool.expr]
 ## Operations on boolean values
 
+r[type.bool.expr.intro]
 When using certain operator expressions with a boolean type for its operands, they evaluate using the rules of [boolean logic].
 
 r[type.bool.expr.not]

src/types/impl-trait.md

@@ -30,10 +30,10 @@ There must be at least one trait bound, no more than one `use<..>` bound, and no
 r[type.impl-trait.param]
 ## Anonymous type parameters
 
+r[type.impl-trait.param.intro]
 > [!NOTE]
 > This is often called "impl Trait in argument position". (The term "parameter" is more correct here, but "impl Trait in argument position" is the phrasing used during the development of this feature, and it remains in parts of the implementation.)
 
-r[type.impl-trait.param.intro]
 Functions can use `impl` followed by a set of trait bounds to declare a parameter as having an anonymous type. The caller must provide a type that satisfies the bounds declared by the anonymous type parameter, and the function can only use the methods available through the trait bounds of the anonymous type parameter.
 
 For example, these two forms are almost equivalent:
@@ -59,10 +59,10 @@ That is, `impl Trait` in argument position is syntactic sugar for a generic type
 r[type.impl-trait.return]
 ## Abstract return types
 
+r[type.impl-trait.return.intro]
 > [!NOTE]
 > This is often called "impl Trait in return position".
 
-r[type.impl-trait.return.intro]
 Functions can use `impl Trait` to return an abstract return type. These types stand in for another concrete type where the caller may only use the methods declared by the specified `Trait`.
 
 r[type.impl-trait.return.constraint-body]

src/unsafe-keyword.md

@@ -73,6 +73,7 @@ Unsafe trait implementations are the logical dual to unsafe traits: where unsafe
 r[unsafe.extern]
 ## Unsafe external blocks (`unsafe extern`)
 
+r[unsafe.extern.intro]
 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]