Add identifier syntax to call-expr

Author: chorman0773

src/expressions/call-expr.md

@@ -1,22 +1,30 @@
 # Call expressions
 
+r[expr.call]
+
+r[expr.call.syntax]
 > **<sup>Syntax</sup>**\
 > _CallExpression_ :\
 > &nbsp;&nbsp; [_Expression_] `(` _CallParams_<sup>?</sup> `)`
 >
 > _CallParams_ :\
 > &nbsp;&nbsp; [_Expression_]&nbsp;( `,` [_Expression_] )<sup>\*</sup> `,`<sup>?</sup>
 
+r[expr.call.intro]
 A *call expression* calls a function.
 The syntax of a call expression is an expression, called the *function operand*, followed by a parenthesized comma-separated list of expression, called the *argument operands*.
+
+r[expr.call.convergence]
 If the function eventually returns, then the expression completes.
 
+r[expr.call.trait]
 For [non-function types], the expression `f(...)` uses the method on one of the following traits based on the function operand:
 
 - [`Fn`] or [`AsyncFn`] --- shared reference.
 - [`FnMut`] or [`AsyncFnMut`] --- mutable reference.
 - [`FnOnce`] or [`AsyncFnOnce`] --- value.
 
+r[expr.call.autoref-deref]
 An automatic borrow will be taken if needed.
 The function operand will also be [automatically dereferenced] as required.
 
@@ -30,20 +38,27 @@ let name: &'static str = (|| "Rust")();
 
 ## Disambiguating Function Calls
 
+r[expr.call.desugar]
+
+r[expr.call.desugar.fully-qualified]
 All function calls are sugar for a more explicit [fully-qualified syntax].
+
+r[expr.call.desugar.ambiguity]
 Function calls may need to be fully qualified, depending on the ambiguity of a call in light of in-scope items.
 
 > **Note**: In the past, the terms "Unambiguous Function Call Syntax", "Universal Function Call Syntax", or "UFCS", have been used in documentation, issues, RFCs, and other community writings.
 > However, these terms lack descriptive power and potentially confuse the issue at hand.
 > We mention them here for searchability's sake.
 
+r[expr.call.desugar.limits]
 Several situations often occur which result in ambiguities about the receiver or referent of method or associated function calls.
 These situations may include:
 
 * Multiple in-scope traits define methods with the same name for the same types
 * Auto-`deref` is undesirable; for example, distinguishing between methods on a smart pointer itself and the pointer's referent
 * Methods which take no arguments, like [`default()`], and return properties of a type, like [`size_of()`]
 
+r[expr.call.desugar.explicit-path]
 To resolve the ambiguity, the programmer may refer to their desired method or function using more specific paths, types, or traits.
 
 For example,