Fix grammar links

src/attributes.md

@@ -110,7 +110,7 @@ r[attributes.meta]
 ## Meta Item Attribute Syntax
 
 r[attributes.meta.intro]
-A "meta item" is the syntax used for the _Attr_ rule by most [built-in
+A "meta item" is the syntax used for the [Attr] rule by most [built-in
 attributes]. It has the following grammar:
 
 r[attributes.meta.syntax]
@@ -185,11 +185,11 @@ Some examples of meta items are:
 
 Style | Example
 ------|--------
-_MetaWord_ | `no_std`
-_MetaNameValueStr_ | `doc = "example"`
-_MetaListPaths_ | `allow(unused, clippy::inline_always)`
-_MetaListIdents_ | `macro_use(foo, bar)`
-_MetaListNameValueStr_ | `link(name = "CoreFoundation", kind = "framework")`
+[MetaWord] | `no_std`
+[MetaNameValueStr] | `doc = "example"`
+[MetaListPaths] | `allow(unused, clippy::inline_always)`
+[MetaListIdents] | `macro_use(foo, bar)`
+[MetaListNameValueStr] | `link(name = "CoreFoundation", kind = "framework")`
 
 r[attributes.activity]
 ## Active and inert attributes

src/attributes/codegen.md

@@ -643,9 +643,7 @@ r[attributes.codegen.instruction_set.behavior]
 This allows mixing more than one instruction set in a single program on CPU architectures that support it.
 
 r[attributes.codegen.instruction_set.syntax]
-It uses the [_MetaListPath_] syntax, and a path comprised of the architecture family name and instruction set name.
-
-[_MetaListPath_]: ../attributes.md#meta-item-attribute-syntax
+It uses the [MetaListPaths] syntax, and a path comprised of the architecture family name and instruction set name.
 
 r[attributes.codegen.instruction_set.target-limits]
 It is a compilation error to use the `instruction_set` attribute on a target that does not support it.

src/expressions/if-expr.md

@@ -35,7 +35,7 @@ The syntax of an `if` expression is a sequence of one or more condition operands
 followed by a consequent block, any number of `else if` conditions and blocks, and an optional trailing `else` block.
 
 r[expr.if.condition]
-Condition operands must be either an [_Expression_] with a [boolean type] or a conditional `let` match.
+Condition operands must be either an [Expression] with a [boolean type] or a conditional `let` match.
 
 r[expr.if.condition-true]
 If all of the condition operands evaluate to `true` and all of the `let` patterns successfully match their [scrutinee]s,
@@ -125,7 +125,7 @@ r[expr.if.chains.intro]
 Multiple condition operands can be separated with `&&`.
 
 r[expr.if.chains.order]
-Similar to a `&&` [_LazyBooleanOperatorExpression_], each operand is evaluated from left-to-right until an operand evaluates as `false` or a `let` match fails,
+Similar to a `&&` [LazyBooleanExpression], each operand is evaluated from left-to-right until an operand evaluates as `false` or a `let` match fails,
 in which case the subsequent operands are not evaluated.
 
 r[expr.if.chains.bindings]
@@ -163,7 +163,7 @@ fn nested() {
 ```
 
 r[expr.if.chains.or]
-If any condition operand is a `let` pattern, then none of the condition operands can be a `||` [lazy boolean operator expression][_LazyBooleanOperatorExpression_] due to ambiguity and precedence with the `let` scrutinee.
+If any condition operand is a `let` pattern, then none of the condition operands can be a `||` [lazy boolean operator expression][expr.bool-logic] due to ambiguity and precedence with the `let` scrutinee.
 If a `||` expression is needed, then parentheses can be used. For example:
 
 ```rust
@@ -178,11 +178,6 @@ r[expr.if.edition2024]
 > [!EDITION-2024]
 > Before the 2024 edition, let chains are not supported. That is, the [LetChain] grammar is not allowed in an `if` expression.
 
-[_BlockExpression_]: block-expr.md
-[_Expression_]: ../expressions.md
-[_LazyBooleanOperatorExpression_]: operator-expr.md#lazy-boolean-operators
-[_Pattern_]: ../patterns.md
-[_Scrutinee_]: match-expr.md
 [`match` expressions]: match-expr.md
 [boolean type]: ../types/boolean.md
 [scrutinee]: ../glossary.md#scrutinee

src/expressions/loop-expr.md

@@ -60,10 +60,10 @@ A `while` loop expression allows repeating the evaluation of a block while a set
 
 r[expr.loop.while.syntax]
 The syntax of a `while` expression is a sequence of one or more condition operands separated by `&&`,
-followed by a [_BlockExpression_].
+followed by a [BlockExpression].
 
 r[expr.loop.while.condition]
-Condition operands must be either an [_Expression_] with a [boolean type] or a conditional `let` match.
+Condition operands must be either an [Expression] with a [boolean type] or a conditional `let` match.
 If all of the condition operands evaluate to `true` and all of the `let` patterns successfully match their [scrutinee]s,
 then the loop body block executes.
 
@@ -392,8 +392,6 @@ r[expr.loop.break-value.loop]
 In the case a `loop` has an associated `break`, it is not considered diverging, and the `loop` must have a type compatible with each `break` expression.
 `break` without an expression is considered identical to `break` with expression `()`.
 
-[_BlockExpression_]: block-expr.md
-[_Expression_]: ../expressions.md
 [`if` condition chains]: if-expr.md#chains-of-conditions
 [`if` expressions]: if-expr.md
 [`match` expression]: match-expr.md

src/expressions/range-expr.md

@@ -30,12 +30,12 @@ The `..` and `..=` operators will construct an object of one of the `std::ops::R
 
 | Production             | Syntax        | Type                         | Range                 |
 |------------------------|---------------|------------------------------|-----------------------|
-| _RangeExpr_            | start`..`end  | [std::ops::Range]            | start ≤ x < end |
-| _RangeFromExpr_        | start`..`     | [std::ops::RangeFrom]        | start ≤ x          |
-| _RangeToExpr_          | `..`end       | [std::ops::RangeTo]          |            x < end |
-| _RangeFullExpr_        | `..`          | [std::ops::RangeFull]        |            -          |
-| _RangeInclusiveExpr_   | start`..=`end | [std::ops::RangeInclusive]   | start ≤ x ≤ end |
-| _RangeToInclusiveExpr_ | `..=`end      | [std::ops::RangeToInclusive] |            x ≤ end |
+| [RangeExpr]            | start`..`end  | [std::ops::Range]            | start ≤ x < end |
+| [RangeFromExpr]        | start`..`     | [std::ops::RangeFrom]        | start ≤ x          |
+| [RangeToExpr]          | `..`end       | [std::ops::RangeTo]          |            x < end |
+| [RangeFullExpr]        | `..`          | [std::ops::RangeFull]        |            -          |
+| [RangeInclusiveExpr]   | start`..=`end | [std::ops::RangeInclusive]   | start ≤ x ≤ end |
+| [RangeToInclusiveExpr] | `..=`end      | [std::ops::RangeToInclusive] |            x ≤ end |
 
 Examples:
 

src/identifiers.md

@@ -51,7 +51,7 @@ Zero width non-joiner (ZWNJ U+200C) and zero width joiner (ZWJ U+200D) character
 r[ident.ascii-limitations]
 Identifiers are restricted to the ASCII subset of [`XID_Start`] and [`XID_Continue`] in the following situations:
 
-* [`extern crate`] declarations (except the _AsClause_ identifier)
+* [`extern crate`] declarations (except the [AsClause] identifier)
 * External crate names referenced in a [path]
 * [Module] names loaded from the filesystem without a [`path` attribute]
 * [`no_mangle`] attributed items

src/items/functions.md

@@ -83,7 +83,7 @@ fn first((value, _): (i32, i32)) -> i32 { value }
 ```
 
 r[items.fn.params.self-pat]
-If the first parameter is a _SelfParam_, this indicates that the function is a
+If the first parameter is a [SelfParam], this indicates that the function is a
 [method].
 
 r[items.fn.params.self-restriction]

src/items/generics.md

@@ -27,7 +27,7 @@ r[items.generics.syntax.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]
-The same parameter name may not be declared more than once in a _GenericParams_ list.
+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:
 

src/macros.md

@@ -58,7 +58,7 @@ r[macro.invocation.extern]
 * [External blocks]
 
 r[macro.invocation.item-statement]
-When used as an item or a statement, the _MacroInvocationSemi_ form is used
+When used as an item or a statement, the [MacroInvocationSemi] form is used
 where a semicolon is required at the end when not using curly braces.
 [Visibility qualifiers] are never allowed before a macro invocation or
 [`macro_rules`] definition.

src/paths.md

@@ -153,7 +153,7 @@ and qualified paths.
 
 r[paths.type.turbofish]
 Although the `::` token is allowed before the generics arguments, it is not required
-because there is no ambiguity like there is in _PathInExpression_.
+because there is no ambiguity like there is in [PathInExpression].
 
 ```rust
 # mod ops {

src/patterns.md

@@ -489,7 +489,7 @@ RangePatternBound ->
     | PathExpression
 ```
 
-[^obsolete-range-edition]: The _ObsoleteRangePattern_ syntax has been removed in the 2021 edition.
+[^obsolete-range-edition]: The [ObsoleteRangePattern] syntax has been removed in the 2021 edition.
 
 r[patterns.range.intro]
 *Range patterns* match scalar values within the range defined by their bounds.
@@ -648,7 +648,7 @@ r[patterns.range.refutable-char]
 The range of values for a `char` type are precisely those ranges containing all Unicode Scalar Values: `'\u{0000}'..='\u{D7FF}'` and `'\u{E000}'..='\u{10FFFF}'`.
 
 r[patterns.range.constraint-slice]
-_RangeFromPattern_ cannot be used as a top-level pattern for subpatterns in [slice patterns](#slice-patterns).
+[RangeFromPattern] cannot be used as a top-level pattern for subpatterns in [slice patterns](#slice-patterns).
 For example, the pattern `[1.., _]` is not a valid pattern.
 
 r[patterns.range.edition2021]
@@ -785,7 +785,7 @@ r[patterns.struct.constraint-union]
 A struct pattern used to match a union must specify exactly one field (see [Pattern matching on unions]).
 
 r[patterns.struct.binding-shorthand]
-The `ref` and/or `mut` _IDENTIFIER_ syntax matches any value and binds it to a variable with the same name as the given field.
+The `ref` and/or `mut` [IDENTIFIER] syntax matches any value and binds it to a variable with the same name as the given field.
 
 ```rust
 # struct Struct {
@@ -799,7 +799,7 @@ let Struct{a: x, b: y, c: z} = struct_value;          // destructure all fields
 ```
 
 r[patterns.struct.refutable]
-A struct pattern is refutable if the _PathInExpression_ resolves to a constructor of an enum with more than one variant, or one of its subpatterns is refutable.
+A struct pattern is refutable if the [PathInExpression] resolves to a constructor of an enum with more than one variant, or one of its subpatterns is refutable.
 
 r[patterns.tuple-struct]
 ## Tuple struct patterns
@@ -816,7 +816,7 @@ Tuple struct patterns match tuple struct and enum values that match all criteria
 They are also used to [destructure](#destructuring) a tuple struct or enum value.
 
 r[patterns.tuple-struct.refutable]
-A tuple struct pattern is refutable if the _PathInExpression_ resolves to a constructor of an enum with more than one variant, or one of its subpatterns is refutable.
+A tuple struct pattern is refutable if the [PathInExpression] resolves to a constructor of an enum with more than one variant, or one of its subpatterns is refutable.
 
 r[patterns.tuple]
 ## Tuple patterns
@@ -985,7 +985,7 @@ r[patterns.or]
 
 _Or-patterns_ are patterns that match on one of two or more sub-patterns (for example `A | B | C`).
 They can nest arbitrarily.
-Syntactically, or-patterns are allowed in any of the places where other patterns are allowed (represented by the _Pattern_ production), with the exceptions of `let`-bindings and function and closure arguments (represented by the _PatternNoTopAlt_ production).
+Syntactically, or-patterns are allowed in any of the places where other patterns are allowed (represented by the [Pattern] production), with the exceptions of `let`-bindings and function and closure arguments (represented by the [PatternNoTopAlt] production).
 
 r[patterns.constraints]
 ### Static semantics

src/types.md

@@ -69,7 +69,7 @@ TypeNoBounds ->
 ```
 
 r[type.name.intro]
-A _type expression_ as defined in the _Type_ grammar rule above is the syntax
+A _type expression_ as defined in the [Type] grammar rule above is the syntax
 for referring to a type. It may refer to:
 
 r[type.name.sequence]