Rex fix formatting nits

standard/classes.md

@@ -172,7 +172,7 @@ interface_type_list
 
 #### 15.2.4.2 Base classes
 
-When a *class_type* is included in the *class_base*, it specifies the direct base class of the class being declared. If a non-partial class declaration has no *class_base*, or if the *class_base* lists only interface types, the direct base class is assumed to be `object`. When a partial class declaration includes a base class specification, that base class specification shall reference the same type as all other parts of that partial type that include a base class specification. If no part of a partial class includes a base class specification, the base class is object. A class inherits members from its direct base class, as described in [§15.3.4](classes.md#1534-inheritance).
+When a *class_type* is included in the *class_base*, it specifies the direct base class of the class being declared. If a non-partial class declaration has no *class_base*, or if the *class_base* lists only interface types, the direct base class is assumed to be `object`. When a partial class declaration includes a base class specification, that base class specification shall reference the same type as all other parts of that partial type that include a base class specification. If no part of a partial class includes a base class specification, the base class is `object`. A class inherits members from its direct base class, as described in [§15.3.4](classes.md#1534-inheritance).
 
 > *Example*: In the following code
 > ```csharp
@@ -216,7 +216,7 @@ In determining the meaning of the direct base class specification `A` of a clas
 > }
 > class Z : X<Z.Y> {}
 > ```
-> is in error since in the base class specification `X<Z.Y>` the direct base class of `Z` is considered to be object, and hence (by the rules of [§8.8](basic-concepts.md#88-namespace-and-type-names)) `Z` is not considered to have a member `Y`. *end example*
+> is in error since in the base class specification `X<Z.Y>` the direct base class of `Z` is considered to be `object`, and hence (by the rules of [§8.8](basic-concepts.md#88-namespace-and-type-names)) `Z` is not considered to have a member `Y`. *end example*
 
 The base classes of a class are the direct base class and its base classes. In other words, the set of base classes is the transitive closure of the direct base class relationship.
 
@@ -478,7 +478,7 @@ The ***dynamic erasure*** of a type `C` is type `Cₓ` constructed as follows:
 -  If `C` `Cₓ`is a constructed type `G<A¹, ..., Aⁿ>` with type arguments `A¹, ..., Aⁿ` then `Cₓ` is the constructed type `G<A¹ₓ, ..., Aⁿₓ>`.
 -  If `C` is an array type `E[]` then `Cₓ` is the array type `Eₓ[]`.
 -  If `C` is a pointer type `E*` then `Cₓ` is the pointer type `Eₓ*`.
--  If `C` is dynamic then `Cₓ` is object.
+-  If `C` is dynamic then `Cₓ` is `object`.
 -  Otherwise, `Cₓ` is `C`.
 
 The ***effective base class*** of a type parameter `T` is defined as follows:
@@ -496,7 +496,7 @@ Then
 
 -  If `T` has the value type constraint, its effective base class is `System.ValueType`.
 -  Otherwise, if `R` is empty then the effective base class is `object`.
--  Otherwise, the effective base class of `T` is the most-encompassed type ([§11.5.3](conversions.md#1153-evaluation-of-user-defined-conversions)) of set `R`. If the set has no encompassed type, the effective base class of `T` is object. The consistency rules ensure that the most-encompassed type exists.
+-  Otherwise, the effective base class of `T` is the most-encompassed type ([§11.5.3](conversions.md#1153-evaluation-of-user-defined-conversions)) of set `R`. If the set has no encompassed type, the effective base class of `T` is `object`. The consistency rules ensure that the most-encompassed type exists.
 
 If the type parameter is a method type parameter whose constraints are inherited from the base method the effective base class is calculated after type substitution.
 
@@ -1584,7 +1584,7 @@ A variable initializer for an instance field cannot reference the instance being
 
 ### 15.6.1 General
 
-A ***method*** is a member that implements a computation or action that can be performed by an `object` or class. Methods are declared using *method_declaration*s:
+A ***method*** is a member that implements a computation or action that can be performed by an object or class. Methods are declared using *method_declaration*s:
 ```ANTLR
 method_declaration
     : method_header method_body
@@ -2659,7 +2659,7 @@ For `abstract` and `extern` properties, the *accessor_body* for each accessor sp
 
 A `get` accessor corresponds to a parameterless method with a return value of the property type. Except as the target of an assignment, when a property is referenced in an expression, the `get` accessor of the property is invoked to compute the value of the property ([§12.2.2](expressions.md#1222-values-of-expressions)). The body of a `get` accessor shall conform to the rules for value-returning methods described in [§15.6.11](classes.md#15611-method-body). In particular, all `return` statements in the body of a `get` accessor shall specify an expression that is implicitly convertible to the property type. Furthermore, the endpoint of a `get` accessor shall not be reachable.
 
-A `set` accessor corresponds to a method with a single value parameter of the property type and a `void` return type. The implicit parameter of a `set` accessor is always named value. When a property is referenced as the target of an assignment ([§12.18](expressions.md#1218-assignment-operators)), or as the operand of `++` or `–-` ([§12.7.10](expressions.md#12710-postfix-increment-and-decrement-operators), [§12.8.6](expressions.md#1286-prefix-increment-and-decrement-operators)), the `set` accessor is invoked with an argument that provides the new value ([§12.18.2](expressions.md#12182-simple-assignment)). The body of a `set` accessor shall conform to the rules for `void` methods described in [§15.6.11](classes.md#15611-method-body). In particular, return statements in the `set` accessor body are not permitted to specify an expression. Since a `set` accessor implicitly has a parameter named `value`, it is a compile-time error for a local variable or constant declaration in a `set` accessor to have that name.
+A `set` accessor corresponds to a method with a single value parameter of the property type and a `void` return type. The implicit parameter of a `set` accessor is always named `value`. When a property is referenced as the target of an assignment ([§12.18](expressions.md#1218-assignment-operators)), or as the operand of `++` or `–-` ([§12.7.10](expressions.md#12710-postfix-increment-and-decrement-operators), [§12.8.6](expressions.md#1286-prefix-increment-and-decrement-operators)), the `set` accessor is invoked with an argument that provides the new value ([§12.18.2](expressions.md#12182-simple-assignment)). The body of a `set` accessor shall conform to the rules for `void` methods described in [§15.6.11](classes.md#15611-method-body). In particular, return statements in the `set` accessor body are not permitted to specify an expression. Since a `set` accessor implicitly has a parameter named `value`, it is a compile-time error for a local variable or constant declaration in a `set` accessor to have that name.
 
 Based on the presence or absence of the `get` and `set` accessors, a property is classified as follows:
 
@@ -2989,7 +2989,7 @@ An overriding property declaration may include the `sealed` modifier. Use of thi
 Except for differences in declaration and invocation syntax, virtual, sealed, override, and abstract accessors behave exactly like virtual, sealed, override and abstract methods. Specifically, the rules described in [§15.6.4](classes.md#1564-virtual-methods), [§15.6.5](classes.md#1565-override-methods), [§15.6.6](classes.md#1566-sealed-methods), and [§15.6.7](classes.md#1567-abstract-methods) apply as if accessors were methods of a corresponding form:
 
 -  A `get` accessor corresponds to a parameterless method with a return value of the property type and the same modifiers as the containing property.
--  A `set` accessor corresponds to a method with a single value parameter of the property type, a void return type, and the same modifiers as the containing property.
+-  A `set` accessor corresponds to a method with a single value parameter of the property type, a `void` return type, and the same modifiers as the containing property.
 
 > *Example*: In the following code
 > ```csharp
@@ -3174,7 +3174,7 @@ Within the program text of the class or struct that contains the declaration of
 > ```
 > which removes a delegate from the invocation list of the `Click` event. *end example*
 
-When compiling a field-like event, the compiler automatically creates storage to hold the delegate, and creates accessors for the event that add or remove event handlers to the delegate field. The addition and removal operations are thread safe, and may (but are not required to) be done while holding the lock ([§10.4.4.19](variables.md#104419-lock-statements)) in the containing object for an instance event, or the type object ([§12.7.11.7](expressions.md#127117-anonymous-object-creation-expressions)) for a static event.
+When compiling a field-like event, the compiler automatically creates storage to hold the delegate, and creates accessors for the event that add or remove event handlers to the delegate field. The addition and removal operations are thread safe, and may (but are not required to) be done while holding the lock ([§10.4.4.19](variables.md#104419-lock-statements)) in the containing object for an instance event, or the type `object` ([§12.7.11.7](expressions.md#127117-anonymous-object-creation-expressions)) for a static event.
 
 > *Note*: Thus, an instance event declaration of the form:
 > ```csharp
@@ -3345,7 +3345,7 @@ Indexers and properties are very similar in concept, but differ in the following
 -  A property is accessed through a *simple_name* ([§12.7.3](expressions.md#1273-simple-names)) or a *member_access* ([§12.7.5](expressions.md#1275-member-access)), whereas an indexer element is accessed through an *element_access* ([§12.7.7.3](expressions.md#12773-indexer-access)).
 -  A property can be a static member, whereas an indexer is always an instance member.
 -  A `get` accessor of a property corresponds to a method with no parameters, whereas a `get` accessor of an indexer corresponds to a method with the same formal parameter list as the indexer.
--  A `set` accessor of a property corresponds to a method with a single parameter named value, whereas a `set` accessor of an indexer corresponds to a method with the same formal parameter list as the indexer, plus an additional parameter named value.
+-  A `set` accessor of a property corresponds to a method with a single parameter named `value`, whereas a `set` accessor of an indexer corresponds to a method with the same formal parameter list as the indexer, plus an additional parameter named `value`.
 -  It is a compile-time error for an indexer accessor to declare a local variable or local constant with the same name as an indexer parameter.
 -  In an overriding property declaration, the inherited property is accessed using the syntax `base.P`, where `P` is the property name. In an overriding indexer declaration, the inherited indexer is accessed using the syntax `base[E]`, where `E` is a comma-separated list of expressions.
 -  There is no concept of an "automatically implemented indexer". It is an error to have a non-abstract, non-external indexer with semicolon accessors.
@@ -3640,7 +3640,7 @@ In cases where a pre-defined conversion exists between two types, any user-defin
     -  If either `S` or `T` is an interface type, user-defined implicit conversions from `S` to `T` are ignored.
     -  Otherwise, user-defined implicit conversions from `S` to `T` are still considered.
 
-For all types but object, the operators declared by the `Convertible<T>` type above do not conflict with pre-defined conversions.
+For all types but `object`, the operators declared by the `Convertible<T>` type above do not conflict with pre-defined conversions.
 
 > *Example*:
 > ```csharp
@@ -3651,7 +3651,7 @@ For all types but object, the operators declared by the `Convertible<T>` type ab
 >     n = (Convertible<int>)i; // User-defined implicit conversion
 > }
 > ```
-> However, for type object, pre-defined conversions hide the user-defined conversions in all cases but one:
+> However, for type `object`, pre-defined conversions hide the user-defined conversions in all cases but one:
 > ```csharp
 > void F(object o, Convertible<object> n) {
 >     o = n; // Pre-defined boxing conversion
@@ -4152,7 +4152,7 @@ The ***enumerable interfaces*** are the non-generic interface `System.Collection
 
 An iterator produces a sequence of values, all of the same type. This type is called the ***yield type*** of the iterator.
 
--  The yield type of an iterator that returns `IEnumerator` or `IEnumerable` is object.
+-  The yield type of an iterator that returns `IEnumerator` or `IEnumerable` is `object`.
 -  The yield type of an iterator that returns `IEnumerator<T>` or `IEnumerable<T>` is `T`.
 
 ### 15.14.5 Enumerator objects
@@ -4258,9 +4258,9 @@ It is a compile-time error for the formal parameter list of an async function to
 
 The *return_type* of an async method shall be either `void` or a ***task type***. The task types are `System.Threading.Tasks.Task` and types constructed from `System.Threading.Tasks.Task<T>`. For the sake of brevity, in this clause these types are referenced as `Task` and `Task<T>`, respectively. An async method returning a task type is said to be ***task-returning***.
 
-The exact definition of the task types is implementation-defined, but from the language's point of view, a task type is in one of the states *incomplete*, *succeeded* or *faulted*. A *faulted* task records a pertinent exception. A *succeeded* `Task<*T*>` records a result of type `*T*`. Task types are awaitable, and tasks can therefore be the operands of await expressions ([§12.8.8](expressions.md#1288-await-expressions)).
+The exact definition of the task types is implementation-defined, but from the language's point of view, a task type is in one of the states *incomplete*, *succeeded* or *faulted*. A *faulted* task records a pertinent exception. A *succeeded* `Task<T>` records a result of type `T`. Task types are awaitable, and tasks can therefore be the operands of await expressions ([§12.8.8](expressions.md#1288-await-expressions)).
 
-An async function has the ability to suspend evaluation by means of await expressions ([§12.8.8](expressions.md#1288-await-expressions)) in its body. Evaluation may later be resumed at the point of the suspending await expression by means of a ***resumption delegate***. The resumption delegate is of type `System.Action`, and when it is invoked, evaluation of the async function invocation will resume from the await expression where it left off. The ***current caller*** of an async function invocation is the original caller if the function invocation has never been suspended or the most recent caller of the resumption delegate otherwise.
+An async function has the ability to suspend evaluation by means of await expressions in its body. Evaluation may later be resumed at the point of the suspending await expression by means of a ***resumption delegate***. The resumption delegate is of type `System.Action`, and when it is invoked, evaluation of the async function invocation will resume from the await expression where it left off. The ***current caller*** of an async function invocation is the original caller if the function invocation has never been suspended or the most recent caller of the resumption delegate otherwise.
 
 ### 15.15.2 Evaluation of a task-returning async function
 

standard/conversions.md

@@ -452,7 +452,7 @@ For a *type_parameter* `T` that is *not* known to be a reference type ([§15.2.5
 
 For a *type_parameter* `T` that is *not* known to be a reference type ([§15.2.5](classes.md#1525-type-parameter-constraints)), the following explicit conversions exist:
 
-- From `T` to any *interface_type* `I` provided there is not already an implicit conversion from `T` to `I`. This conversion consists of an implicit boxing conversion ([§11.2.8](conversions.md#1128-boxing-conversions)) from `T` to object followed by an explicit reference conversion from object to `I`. At run-time, if `T` is a value type, the conversion is executed as a boxing conversion followed by an explicit reference conversion. At run-time, if `T` is a reference type, the conversion is executed as an explicit reference conversion.
+- From `T` to any *interface_type* `I` provided there is not already an implicit conversion from `T` to `I`. This conversion consists of an implicit boxing conversion ([§11.2.8](conversions.md#1128-boxing-conversions)) from `T` to `object` followed by an explicit reference conversion from `object` to `I`. At run-time, if `T` is a value type, the conversion is executed as a boxing conversion followed by an explicit reference conversion. At run-time, if `T` is a reference type, the conversion is executed as an explicit reference conversion.
 - From a type parameter `U` to `T` provided that `T` depends on `U` ([§15.2.5](classes.md#1525-type-parameter-constraints)). At run-time, if `T` is a value type and `U` is a reference type, the conversion is executed as an unboxing conversion. At run-time, if both `T` and `U` are value types, then `T` and `U` are necessarily the same type and no conversion is performed. At run-time, if `T` is a reference type, then `U` is necessarily also a reference type and the conversion is executed as an explicit reference conversion or identity conversion.
 
 In all cases, the rules ensure that a conversion is executed as an unboxing conversion if and only if at run-time the conversion is from a reference type to a value type.