Add identifier syntax to closure-expr, field-expr, and grouped-expr

Author: chorman0773

src/expressions/closure-expr.md

@@ -1,5 +1,8 @@
 # Closure expressions
 
+r[expr.closure]
+
+r[expr.closure.syntax]
 > **<sup>Syntax</sup>**\
 > _ClosureExpression_ :\
 > &nbsp;&nbsp; `async`[^cl-async-edition]<sup>?</sup>\
@@ -15,23 +18,40 @@
 >
 > [^cl-async-edition]: The `async` qualifier is not allowed in the 2015 edition.
 
+r[expr.closure.intro]
 A *closure expression*, also known as a lambda expression or a lambda, defines a [closure type] and evaluates to a value of that type.
 The syntax for a closure expression is an optional `async` keyword, an optional `move` keyword, then a pipe-symbol-delimited (`|`) comma-separated list of [patterns], called the *closure parameters* each optionally followed by a `:` and a type, then an optional `->` and type, called the *return type*, and then an expression, called the *closure body operand*.
+
+r[expr.closure.param-type]
 The optional type after each pattern is a type annotation for the pattern.
+
+r[expr.closure.explicit-type-body]
 If there is a return type, the closure body must be a [block].
 
+r[expr.closure.parameter-restriction]
 A closure expression denotes a function that maps a list of parameters onto the expression that follows the parameters.
 Just like a [`let` binding], the closure parameters are irrefutable [patterns], whose type annotation is optional and will be inferred from context if not given.
+
+r[expr.closure.unique-type]
 Each closure expression has a unique, anonymous type.
 
+r[expr.closure.captures]
 Significantly, closure expressions _capture their environment_, which regular [function definitions] do not.
+
+r[expr.closure.capture-inference]
 Without the `move` keyword, the closure expression [infers how it captures each variable from its environment](../types/closure.md#capture-modes), preferring to capture by shared reference, effectively borrowing all outer variables mentioned inside the closure's body.
+
+r[expr.closure.capture-mut-ref]
 If needed the compiler will infer that instead mutable references should be taken, or that the values should be moved or copied (depending on their type) from the environment.
+
+r[expr.closure.capture-move]
 A closure can be forced to capture its environment by copying or moving values by prefixing it with the `move` keyword.
 This is often used to ensure that the closure's lifetime is `'static`.
 
 ## Closure trait implementations
 
+r[expr.closure.trait-impl]
+
 Which traits the closure type implement depends on how variables are captured, the types of the captured variables, and the presence of `async`.
 See the [call traits and coercions] chapter for how and when a closure implements `Fn`, `FnMut`, and `FnOnce`.
 The closure type implements [`Send`] and [`Sync`] if the type of every captured variable also implements the trait.
@@ -79,6 +99,8 @@ ten_times(move |j| println!("{}, {}", word, j));
 
 ## Attributes on closure parameters
 
+r[expr.closure.param-attributes]
+
 Attributes on closure parameters follow the same rules and restrictions as [regular function parameters].
 
 [_Expression_]: ../expressions.md

src/expressions/field-expr.md

@@ -1,13 +1,22 @@
 # Field access expressions
 
+r[expr.field]
+
+r[expr.field.syntax]
 > **<sup>Syntax</sup>**\
 > _FieldExpression_ :\
 > &nbsp;&nbsp; [_Expression_] `.` [IDENTIFIER]
 
+r[expr.field.intro]
 A *field expression* is a [place expression] that evaluates to the location of a field of a [struct] or [union].
+
+r[expr.field.mut]
 When the operand is [mutable], the field expression is also mutable.
 
+r[expr.field.form]
 The syntax for a field expression is an expression, called the *container operand*, then a `.`, and finally an [identifier].
+
+r[expr.field.constraint]
 Field expressions cannot be followed by a parenthetical comma-separated list of expressions, as that is instead parsed as a [method call expression].
 That is, they cannot be the function operand of a [call expression].
 
@@ -36,11 +45,15 @@ foo().x;
 
 ## Automatic dereferencing
 
+r[expr.field.autoref-deref]
+
 If the type of the container operand implements [`Deref`] or [`DerefMut`][`Deref`] depending on whether the operand is [mutable], it is *automatically dereferenced* as many times as necessary to make the field access possible.
 This process is also called *autoderef* for short.
 
 ## Borrowing
 
+r[expr.field.borrow]
+
 The fields of a struct or a reference to a struct are treated as separate entities when borrowing.
 If the struct does not implement [`Drop`] and is stored in a local variable, this also applies to moving out of each of its fields.
 This also does not apply if automatic dereferencing is done though user-defined types other than [`Box`].

src/expressions/grouped-expr.md

@@ -1,16 +1,24 @@
 # Grouped expressions
 
+r[expr.paren]
+
+r[expr.paren.syntax]
 > **<sup>Syntax</sup>**\
 > _GroupedExpression_ :\
 > &nbsp;&nbsp; `(` [_Expression_] `)`
 
+r[expr.paren.intro]
 A *parenthesized expression* wraps a single expression, evaluating to that expression.
 The syntax for a parenthesized expression is a `(`, then an expression, called the *enclosed operand*, and then a `)`.
 
+r[expr.paren.evaluation]
 Parenthesized expressions evaluate to the value of the enclosed operand.
+
+r[expr.paren.place-or-value]
 Unlike other expressions, parenthesized expressions are both [place expressions and value expressions][place].
 When the enclosed operand is a place expression, it is a place expression and when the enclosed operand is a value expression, it is a value expression.
 
+r[expr.paren.overridew-precedence]
 Parentheses can be used to explicitly modify the precedence order of subexpressions within an expression.
 
 An example of a parenthesized expression: