Fix rule IDs not following the header hierarchy

src/attributes.md

@@ -142,7 +142,7 @@ fn foo() {}
 r[attributes.meta.builtin]
 Various built-in attributes use different subsets of the meta item syntax to specify their inputs. The following grammar rules show some commonly used forms:
 
-r[attributes.meta.builtin.syntax]
+r[attributes.meta.builtin-syntax]
 ```grammar,attributes
 @root MetaWord ->
     IDENTIFIER

src/conditional-compilation.md

@@ -39,19 +39,19 @@ Whether to compile can depend on the target architecture of the compiled crate,
 r[cfg.predicate]
 Each form of conditional compilation takes a _configuration predicate_ that evaluates to true or false. The predicate is one of the following:
 
-r[cfg.predicate.option]
+r[cfg.predicate-option]
 * A configuration option. The predicate is true if the option is set, and false if it is unset.
 
-r[cfg.predicate.all]
+r[cfg.predicate-all]
 * `all()` with a comma-separated list of configuration predicates. It is true if all of the given predicates are true, or if the list is empty.
 
-r[cfg.predicate.any]
+r[cfg.predicate-any]
 * `any()` with a comma-separated list of configuration predicates. It is true if at least one of the given predicates is true. If there are no predicates, it is false.
 
-r[cfg.predicate.not]
+r[cfg.predicate-not]
 * `not()` with a configuration predicate. It is true if its predicate is false and false if its predicate is true.
 
-r[cfg.predicate.literal]
+r[cfg.predicate-literal]
 * `true` or `false` literals, which are always true or false respectively.
 
 r[cfg.option-spec]

src/destructors.md

@@ -86,31 +86,31 @@ r[destructors.scope.match-arm]
 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.
 
-r[destructors.scope.nesting.function]
+r[destructors.scope.nesting-function]
 * The entire function scope is the outer most scope.
 
-r[destructors.scope.nesting.function-body]
+r[destructors.scope.nesting-function-body]
 * The function body block is contained within the scope of the entire function.
 
-r[destructors.scope.nesting.expr-statement]
+r[destructors.scope.nesting-expr-statement]
 * The parent of the expression in an expression statement is the scope of the statement.
 
-r[destructors.scope.nesting.let-initializer]
+r[destructors.scope.nesting-let-initializer]
 * The parent of the initializer of a [`let` statement] is the `let` statement's scope.
 
-r[destructors.scope.nesting.statement]
+r[destructors.scope.nesting-statement]
 * The parent of a statement scope is the scope of the block that contains the statement.
 
-r[destructors.scope.nesting.match-guard]
+r[destructors.scope.nesting-match-guard]
 * The parent of the expression for a `match` guard is the scope of the arm that the guard is for.
 
-r[destructors.scope.nesting.match-arm]
+r[destructors.scope.nesting-match-arm]
 * The parent of the expression after the `=>` in a `match` expression is the scope of the arm that it's in.
 
-r[destructors.scope.nesting.match]
+r[destructors.scope.nesting-match]
 * The parent of the arm scope is the scope of the `match` expression that it belongs to.
 
-r[destructors.scope.nesting.other]
+r[destructors.scope.nesting-other]
 * The parent of all other scopes is the scope of the immediately enclosing expression.
 
 r[destructors.scope.params]

src/inline-assembly.md

@@ -305,7 +305,7 @@ r[asm.operand-type]
 r[asm.operand-type.supported-operands]
 Several types of operands are supported:
 
-r[asm.operand-type.supported-operands.in]
+r[asm.operand-type.supported-operands-in]
 * `in(<reg>) <expr>`
   - `<reg>` can refer to a register class or an explicit register. The allocated register name is substituted into the asm template string.
   - The allocated register will contain the value of `<expr>` at the start of the assembly code.
@@ -321,7 +321,7 @@ unsafe { core::arch::asm!("/* {} */", in(reg) 5); }
 > [!NOTE]
 > If the value's type is smaller than the register, the value of the upper bits is platform-specific. Some targets zero out the upper bits, while others leave them untouched.
 
-r[asm.operand-type.supported-operands.out]
+r[asm.operand-type.supported-operands-out]
 * `out(<reg>) <expr>`
   - `<reg>` can refer to a register class or an explicit register. The allocated register name is substituted into the asm template string.
   - The allocated register will contain an undefined value at the start of the assembly code.
@@ -336,7 +336,7 @@ unsafe { core::arch::asm!("/* {} */", out(reg) x); }
 # }
 ```
 
-r[asm.operand-type.supported-operands.lateout]
+r[asm.operand-type.supported-operands-lateout]
 * `lateout(<reg>) <expr>`
   - Identical to `out` except that the register allocator can reuse a register allocated to an `in`.
   - You should only write to the register after all inputs are read, otherwise you may clobber an input.
@@ -352,7 +352,7 @@ assert_eq!(x, 5)
 # }
 ```
 
-r[asm.operand-type.supported-operands.inout]
+r[asm.operand-type.supported-operands-inout]
 * `inout(<reg>) <expr>`
   - `<reg>` can refer to a register class or an explicit register. The allocated register name is substituted into the asm template string.
   - The allocated register will contain the value of `<expr>` at the start of the assembly code.
@@ -367,7 +367,7 @@ assert_eq!(x, 5);
 # }
 ```
 
-r[asm.operand-type.supported-operands.inout-arrow]
+r[asm.operand-type.supported-operands-inout-arrow]
 * `inout(<reg>) <in expr> => <out expr>`
   - Same as `inout` except that the initial value of the register is taken from the value of `<in expr>`.
   - `<out expr>` must be a (possibly uninitialized) place expression, to which the contents of the allocated register are written at the end of the assembly code.
@@ -383,7 +383,7 @@ assert_eq!(x, 5);
 # }
 ```
 
-r[asm.operand-type.supported-operands.inlateout]
+r[asm.operand-type.supported-operands-inlateout]
 * `inlateout(<reg>) <expr>` / `inlateout(<reg>) <in expr> => <out expr>`
   - Identical to `inout` except that the register allocator can reuse a register allocated to an `in` (this can happen if the compiler knows the `in` has the same initial value as the `inlateout`).
   - You should only write to the register after all inputs are read, otherwise you may clobber an input.
@@ -397,7 +397,7 @@ assert_eq!(x, 5);
 # }
 ```
 
-r[asm.operand-type.supported-operands.sym]
+r[asm.operand-type.supported-operands-sym]
 * `sym <path>`
   - `<path>` must refer to a `fn` or `static`.
   - A mangled symbol name referring to the item is substituted into the asm template string.
@@ -415,7 +415,7 @@ unsafe { core::arch::asm!("call {}", sym foo, clobber_abi("C")); }
 # }
 ```
 
-r[asm.operand-type.supported-operands.const]
+r[asm.operand-type.supported-operands-const]
 * `const <expr>`
   - `<expr>` must be an integer constant expression. This expression follows the same rules as inline `const` blocks.
   - The type of the expression may be any integer type, but defaults to `i32` just like integer literals.
@@ -439,7 +439,7 @@ assert_eq!(y, [3, 2, 0, 1]);
 # }
 ```
 
-r[asm.operand-type.supported-operands.label]
+r[asm.operand-type.supported-operands-label]
 * `label <block>`
   - The address of the block is substituted into the asm template string. The assembly code may jump to the substituted address.
   - For targets that distinguish between direct jumps and indirect jumps (e.g. x86-64 with `cf-protection` enabled), the assembly code must not jump to the substituted address indirectly.
@@ -1075,7 +1075,7 @@ r[asm.options]
 r[asm.options.supported-options]
 Flags are used to further influence the behavior of the inline assembly code. Currently the following options are defined:
 
-r[asm.options.supported-options.pure]
+r[asm.options.supported-options-pure]
 - `pure`: The assembly code has no side effects, must eventually return, and its outputs depend only on its direct inputs (i.e. the values themselves, not what they point to) or values read from memory (unless the `nomem` options is also set). This allows the compiler to execute the assembly code fewer times than specified in the program (e.g. by hoisting it out of a loop) or even eliminate it entirely if the outputs are not used. The `pure` option must be combined with either the `nomem` or `readonly` options, otherwise a compile-time error is emitted.
 
 ```rust
@@ -1101,7 +1101,7 @@ assert_eq!(z, 0);
 # #[cfg(not(target_arch = "x86_64"))] core::compile_error!("Test not supported on this arch");
 ```
 
-r[asm.options.supported-options.nomem]
+r[asm.options.supported-options-nomem]
 - `nomem`: The assembly code does not read from or write to any memory accessible outside of the assembly code. This allows the compiler to cache the values of modified global variables in registers across execution of the assembly code since it knows that they are not read from or written to by it. The compiler also assumes that the assembly code does not perform any kind of synchronization with other threads, e.g. via fences.
 
 <!-- no_run: This test has unpredictable or undefined behavior at runtime -->
@@ -1147,7 +1147,7 @@ assert_eq!(z, 1);
 # }
 ```
 
-r[asm.options.supported-options.readonly]
+r[asm.options.supported-options-readonly]
 - `readonly`: The assembly code does not write to any memory accessible outside of the assembly code. This allows the compiler to cache the values of unmodified global variables in registers across execution of the assembly code since it knows that they are not written to by it. The compiler also assumes that this assembly code does not perform any kind of synchronization with other threads, e.g. via fences.
 
 <!-- no_run: This test has undefined behaviour at runtime -->
@@ -1191,10 +1191,10 @@ assert_eq!(z, 1);
 # }
 ```
 
-r[asm.options.supported-options.preserves_flags]
+r[asm.options.supported-options-preserves_flags]
 - `preserves_flags`: The assembly code does not modify the flags register (defined in the rules below). This allows the compiler to avoid recomputing the condition flags after execution of the assembly code.
 
-r[asm.options.supported-options.noreturn]
+r[asm.options.supported-options-noreturn]
 - `noreturn`: The assembly code does not fall through; behavior is undefined if it does. It may still jump to `label` blocks. If any `label` blocks return unit, the `asm!` block will return unit. Otherwise it will return `!` (never). As with a call to a function that does not return, local variables in scope are not dropped before execution of the assembly code.
 
 <!-- no_run: This test aborts at runtime -->
@@ -1226,7 +1226,7 @@ let _: () = unsafe {
 };
 ```
 
-r[asm.options.supported-options.nostack]
+r[asm.options.supported-options-nostack]
 - `nostack`: The assembly code does not push data to the stack, or write to the stack red-zone (if supported by the target). If this option is *not* used then the stack pointer is guaranteed by the compiler at the start of the assembly code to be suitably aligned (according to the target ABI) for a function call.
 
 <!-- no_run: Test has undefined behavior at runtime -->
@@ -1237,7 +1237,7 @@ unsafe { core::arch::asm!("push rax", "pop rax", options(nostack)); }
 # }
 ```
 
-r[asm.options.supported-options.att_syntax]
+r[asm.options.supported-options-att_syntax]
 - `att_syntax`: This option is only valid on x86, and causes the assembler to use the `.att_syntax prefix` mode of the GNU assembler. Register operands are substituted in with a leading `%`.
 
 ```rust
@@ -1256,13 +1256,13 @@ assert_eq!(x, y);
 # }
 ```
 
-r[asm.options.supported-options.raw]
+r[asm.options.supported-options-raw]
 - `raw`: This causes the template string to be parsed as a raw assembly string, with no special handling for `{` and `}`. This is primarily useful when including raw assembly code from an external file using `include_str!`.
 
 r[asm.options.checks]
 The compiler performs some additional checks on options:
 
-r[asm.options.checks.mutually-exclusive]
+r[asm.options.checks-mutually-exclusive]
 - The `nomem` and `readonly` options are mutually exclusive: it is a compile-time error to specify both.
 
 ```rust,compile_fail
@@ -1274,7 +1274,7 @@ unsafe { core::arch::asm!("", options(nomem, readonly)); }
 # #[cfg(not(target_arch = "x86_64"))] core::compile_error!("Test not supported on this arch");
 ```
 
-r[asm.options.checks.pure]
+r[asm.options.checks-pure]
 - It is a compile-time error to specify `pure` on an asm block with no outputs or only discarded outputs (`_`).
 
 ```rust,compile_fail
@@ -1286,7 +1286,7 @@ unsafe { core::arch::asm!("", options(pure)); }
 # #[cfg(not(target_arch = "x86_64"))] core::compile_error!("Test not supported on this arch");
 ```
 
-r[asm.options.checks.noreturn]
+r[asm.options.checks-noreturn]
 - It is a compile-time error to specify `noreturn` on an asm block with outputs and without labels.
 
 ```rust,compile_fail
@@ -1299,7 +1299,7 @@ unsafe { core::arch::asm!("mov {:e}, 1", out(reg) z, options(noreturn)); }
 # #[cfg(not(target_arch = "x86_64"))] core::compile_error!("Test not supported on this arch");
 ```
 
-r[asm.options.checks.label-with-outputs]
+r[asm.options.checks-label-with-outputs]
 - It is a compile-time error to have any `label` blocks in an asm block with outputs.
 
 r[asm.options.naked_asm-restriction]

src/introduction.md

@@ -107,7 +107,7 @@ These conventions are documented here.
 * The grammar and lexical productions are described in the [Notation] chapter.
 
 r[example.rule.label]
-* Rule identifiers appear before each language rule enclosed in square brackets. These identifiers provide a way to refer to and link to a specific rule in the language ([e.g.][example rule]). The rule identifier uses periods to separate sections from most general to most specific ([destructors.scope.nesting.function-body] for example). On narrow screens, the rule name will collapse to display `[*]`.
+* Rule identifiers appear before each language rule enclosed in square brackets. These identifiers provide a way to refer to and link to a specific rule in the language ([e.g.][example rule]). The rule identifier uses periods to separate sections from most general to most specific ([destructors.scope.nesting-function-body] for example). On narrow screens, the rule name will collapse to display `[*]`.
 
   The rule name can be clicked to link to that rule.
 

src/items/associated-items.md

@@ -231,7 +231,7 @@ There is an implicit [`Sized`] bound on associated types that can be relaxed usi
 r[items.associated.type.def]
 An *associated type definition* defines a type alias for the implementation of a trait on a type.
 
-r[items.associated.type.def.restriction]
+r[items.associated.type.def-restriction]
 They are written similarly to an *associated type declaration*, but cannot contain `Bounds`, but instead must contain a `Type`:
 
 <!-- ignore: illustrative example forms -->

src/items/external-blocks.md

@@ -275,10 +275,10 @@ The `name` key must be included if `kind` is specified.
 r[items.extern.attributes.link.modifiers]
 The optional `modifiers` argument is a way to specify linking modifiers for the library to link.
 
-r[items.extern.attributes.link.modifiers.syntax]
+r[items.extern.attributes.link.modifiers-syntax]
 Modifiers are specified as a comma-delimited string with each modifier prefixed with either a `+` or `-` to indicate that the modifier is enabled or disabled, respectively.
 
-r[items.extern.attributes.link.modifiers.multiple]
+r[items.extern.attributes.link.modifiers-multiple]
 Specifying multiple `modifiers` arguments in a single `link` attribute, or multiple identical modifiers in the same `modifiers` argument is not currently supported. Example: `#[link(name = "mylib", kind = "static", modifiers = "+whole-archive")]`.
 
 r[items.extern.attributes.link.wasm_import_module]
@@ -305,53 +305,53 @@ unsafe extern {
 r[items.extern.attributes.link.empty-block]
 It is valid to add the `link` attribute on an empty extern block. You can use this to satisfy the linking requirements of extern blocks elsewhere in your code (including upstream crates) instead of adding the attribute to each extern block.
 
-r[items.extern.attributes.link.modifiers.bundle]
+r[items.extern.attributes.link.modifiers-bundle]
 #### Linking modifiers: `bundle`
 
-r[items.extern.attributes.link.modifiers.bundle.allowed-kinds]
+r[items.extern.attributes.link.modifiers-bundle.allowed-kinds]
 This modifier is only compatible with the `static` linking kind. Using any other kind will result in a compiler error.
 
-r[items.extern.attributes.link.modifiers.bundle.behavior]
+r[items.extern.attributes.link.modifiers-bundle.behavior]
 When building a rlib or staticlib `+bundle` means that the native static library will be packed into the rlib or staticlib archive, and then retrieved from there during linking of the final binary.
 
-r[items.extern.attributes.link.modifiers.bundle.behavior-negative]
+r[items.extern.attributes.link.modifiers-bundle.behavior-negative]
 When building a rlib `-bundle` means that the native static library is registered as a dependency of that rlib "by name", and object files from it are included only during linking of the final binary, the file search by that name is also performed during final linking. When building a staticlib `-bundle` means that the native static library is simply not included into the archive and some higher level build system will need to add it later during linking of the final binary.
 
-r[items.extern.attributes.link.modifiers.bundle.no-effect]
+r[items.extern.attributes.link.modifiers-bundle.no-effect]
 This modifier has no effect when building other targets like executables or dynamic libraries.
 
-r[items.extern.attributes.link.modifiers.bundle.default]
+r[items.extern.attributes.link.modifiers-bundle.default]
 The default for this modifier is `+bundle`.
 
 More implementation details about this modifier can be found in [`bundle` documentation for rustc].
 
-r[items.extern.attributes.link.modifiers.whole-archive]
+r[items.extern.attributes.link.modifiers-whole-archive]
 #### Linking modifiers: `whole-archive`
 
-r[items.extern.attributes.link.modifiers.whole-archive.allowed-kinds]
+r[items.extern.attributes.link.modifiers-whole-archive.allowed-kinds]
 This modifier is only compatible with the `static` linking kind. Using any other kind will result in a compiler error.
 
-r[items.extern.attributes.link.modifiers.whole-archive.behavior]
+r[items.extern.attributes.link.modifiers-whole-archive.behavior]
 `+whole-archive` means that the static library is linked as a whole archive without throwing any object files away.
 
-r[items.extern.attributes.link.modifiers.whole-archive.default]
+r[items.extern.attributes.link.modifiers-whole-archive.default]
 The default for this modifier is `-whole-archive`.
 
 More implementation details about this modifier can be found in [`whole-archive` documentation for rustc].
 
-r[items.extern.attributes.link.modifiers.verbatim]
+r[items.extern.attributes.link.modifiers-verbatim]
 #### Linking modifiers: `verbatim`
 
-r[items.extern.attributes.link.modifiers.verbatim.allowed-kinds]
+r[items.extern.attributes.link.modifiers-verbatim.allowed-kinds]
 This modifier is compatible with all linking kinds.
 
-r[items.extern.attributes.link.modifiers.verbatim.behavior]
+r[items.extern.attributes.link.modifiers-verbatim.behavior]
 `+verbatim` means that rustc itself won't add any target-specified library prefixes or suffixes (like `lib` or `.a`) to the library name, and will try its best to ask for the same thing from the linker.
 
-r[items.extern.attributes.link.modifiers.verbatim.behavior-negative]
+r[items.extern.attributes.link.modifiers-verbatim.behavior-negative]
 `-verbatim` means that rustc will either add a target-specific prefix and suffix to the library name before passing it to linker, or won't prevent linker from implicitly adding it.
 
-r[items.extern.attributes.link.modifiers.verbatim.default]
+r[items.extern.attributes.link.modifiers-verbatim.default]
 The default for this modifier is `-verbatim`.
 
 More implementation details about this modifier can be found in [`verbatim` documentation for rustc].