Convert remaining grammar rule references to links

In rust-lang#1787 I missed linkify-ing
references to grammar rules that weren't links. This makes sure that
they are linked and validated.

Author: ehuss

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