Add identifier syntax to method-call-expr and operator-expr

Author: chorman0773

src/expressions/method-call-expr.md

@@ -1,10 +1,16 @@
 # Method-call expressions
 
+r[expr.method]
+
+r[expr.method.syntax]
 > **<sup>Syntax</sup>**\
 > _MethodCallExpression_ :\
 > &nbsp;&nbsp; [_Expression_] `.` [_PathExprSegment_] `(`[_CallParams_]<sup>?</sup> `)`
 
+r[expr.method.intro]
 A _method call_ consists of an expression (the *receiver*) followed by a single dot, an expression path segment, and a parenthesized expression-list.
+
+r[expr.method.target]
 Method calls are resolved to associated [methods] on specific traits, either statically dispatching to a method if the exact `self`-type of the left-hand-side is known, or dynamically dispatching if the left-hand-side expression is an indirect [trait object](../types/trait-object.md).
 
 ```rust
@@ -13,16 +19,21 @@ let log_pi = pi.unwrap_or(1.0).log(2.72);
 # assert!(1.14 < log_pi && log_pi < 1.15)
 ```
 
+r[expr.method.autoref-deref]
 When looking up a method call, the receiver may be automatically dereferenced or borrowed in order to call a method.
 This requires a more complex lookup process than for other functions, since there may be a number of possible methods to call.
 The following procedure is used:
 
+r[expr.method.candidate-recievers]
 The first step is to build a list of candidate receiver types.
 Obtain these by repeatedly [dereferencing][dereference] the receiver expression's type, adding each type encountered to the list, then finally attempting an [unsized coercion] at the end, and adding the result type if that is successful.
+
+r[expr.method.candidate-recievers-refs]
 Then, for each candidate `T`, add `&T` and `&mut T` to the list immediately after `T`.
 
 For instance, if the receiver has type `Box<[i32;2]>`, then the candidate types will be `Box<[i32;2]>`, `&Box<[i32;2]>`, `&mut Box<[i32;2]>`, `[i32; 2]` (by dereferencing), `&[i32; 2]`, `&mut [i32; 2]`, `[i32]` (by unsized coercion), `&[i32]`, and finally `&mut [i32]`.
 
+r[expr.method.candidate-search]
 Then, for each candidate type `T`, search for a [visible] method with a receiver of that type in the following places:
 
 1. `T`'s inherent methods (methods implemented directly on `T`).
@@ -58,11 +69,14 @@ Then, for each candidate type `T`, search for a [visible] method with a receiver
 > }
 > ```
 
+r[expr.method.ambiguious-target]
 If this results in multiple possible candidates, then it is an error, and the receiver must be [converted][disambiguate call] to an appropriate receiver type to make the method call.
 
+r[expr.method.constraint]
 This process does not take into account the mutability or lifetime of the receiver, or whether a method is `unsafe`.
 Once a method is looked up, if it can't be called for one (or more) of those reasons, the result is a compiler error.
 
+r[expr.method.ambiguious-search]
 If a step is reached where there is more than one possible method, such as where generic methods or traits are considered the same, then it is a compiler error.
 These cases require a [disambiguating function call syntax] for method and function invocation.