Start by running add-hyperlinks-to-numbered-sections.js for the new f…

…iles

Also manually fixed a couple typo link syntax

docs/i.11-collected-common-language-specification-rules.md

@@ -26,11 +26,11 @@ The complete set of CLS rules are collected here for reference. Recall that thes
 
 **CLS Rule 12:** The visibility and accessibility of types and members shall be such that types in the signature of any member shall be visible and accessible whenever the member itself is visible and accessible. For example, a public method that is visible outside its assembly shall not have an argument whose type is visible only within the assembly. The visibility and accessibility of types composing an instantiated generic type used in the signature of any member shall be visible and accessible whenever the member itself is visible and accessible. For example, an instantiated generic type present in the signature of a member that is visible outside its assembly shall not have a generic argument whose type is visible only within the assembly. (§[I.8.6.1](i.8.6.1-signatures.md))
 
-**CLS Rule 13:** The value of a literal static is specified through the use of field initialization metadata (see Partition II Metadata). A CLS-compliant literal must have a value specified in field initialization metadata that is of exactly the same type as the literal (or of the underlying type, if that literal is an enum). (§[I.8.6.1.2](#todo-missing-hyperlink))
+**CLS Rule 13:** The value of a literal static is specified through the use of field initialization metadata (see Partition II Metadata). A CLS-compliant literal must have a value specified in field initialization metadata that is of exactly the same type as the literal (or of the underlying type, if that literal is an enum). (§[I.8.6.1.2](i.8.6.1.2-location-signatures.md))
 
-**CLS Rule 14:** Typed references are not CLS-compliant. (§[I.8.6.1.3](#todo-missing-hyperlink))
+**CLS Rule 14:** Typed references are not CLS-compliant. (§[I.8.6.1.3](i.8.6.1.3-local-signatures.md))
 
-**CLS Rule 15:** The vararg constraint is not part of the CLS, and the only calling convention supported by the CLS is the standard managed calling convention. (§[I.8.6.1.5](#todo-missing-hyperlink))
+**CLS Rule 15:** The vararg constraint is not part of the CLS, and the only calling convention supported by the CLS is the standard managed calling convention. (§[I.8.6.1.5](i.8.6.1.5-method-signatures.md))
 
 **CLS Rule 16:** Arrays shall have elements with a CLS-compliant type, and all dimensions of the array shall have lower bounds of zero. Only the fact that an item is an array and the element type of the array shall be required to distinguish between overloads.  When overloading is based on two or more array types the element types shall be named types. (§[I.8.9.1](i.8.9.1-array-types.md))
 

docs/i.8.2.1.1-managed-pointers-and-related-types.md

@@ -1,9 +1,9 @@
 ## I.8.2.1.1 Managed pointers and related types
 
-A **managed pointer** (§[I.12.1.1.2](i.12.1.1.2-object-reference-and-managed-pointer-types-o-and-ref.md)), or **byref** (§[I.8.6.1.3](#todo-missing-hyperlink), §[I.12.4.1.5.2](i.12.4.1.5.2-by-reference-parameters.md)), can point to a local variable, parameter, field of a compound type, or element of an array. However, when a call crosses a remoting boundary (see §[I.12.5](i.12.5-proxies-and-remoting.md)) a conforming implementation can use a copy-in/copyout mechanism instead of a managed pointer. Thus programs shall not rely on the aliasing behavior of true pointers. Managed pointer types are only allowed for  local variable (§[I.8.6.1.3](#todo-missing-hyperlink)) and parameter signatures (§[I.8.6.1.4](#todo-missing-hyperlink)); they cannot be used for field signatures (§[I.8.6.1.2](#todo-missing-hyperlink)), as the element type of an array (§[I.8.9.1](i.8.9.1-array-types.md)), and boxing a value of managed pointer type is disallowed (§[I.8.2.4](i.8.2.4-boxing-and-unboxing-of-values.md)). Using a managed pointer type for the return type of methods (§[I.8.6.1.5](#todo-missing-hyperlink)) is not verifiable (§[I.8.8](i.8.8-type-safety-and-verification.md)).
+A **managed pointer** (§[I.12.1.1.2](i.12.1.1.2-object-reference-and-managed-pointer-types-o-and-ref.md)), or **byref** (§[I.8.6.1.3](i.8.6.1.3-local-signatures.md), §[I.12.4.1.5.2](i.12.4.1.5.2-by-reference-parameters.md)), can point to a local variable, parameter, field of a compound type, or element of an array. However, when a call crosses a remoting boundary (see §[I.12.5](i.12.5-proxies-and-remoting.md)) a conforming implementation can use a copy-in/copyout mechanism instead of a managed pointer. Thus programs shall not rely on the aliasing behavior of true pointers. Managed pointer types are only allowed for  local variable (§[I.8.6.1.3](i.8.6.1.3-local-signatures.md)) and parameter signatures (§[I.8.6.1.4](i.8.6.1.4-paramater-signatures.md)); they cannot be used for field signatures (§[I.8.6.1.2](i.8.6.1.2-location-signatures.md)), as the element type of an array (§[I.8.9.1](i.8.9.1-array-types.md)), and boxing a value of managed pointer type is disallowed (§[I.8.2.4](i.8.2.4-boxing-and-unboxing-of-values.md)). Using a managed pointer type for the return type of methods (§[I.8.6.1.5](i.8.6.1.5-method-signatures.md)) is not verifiable (§[I.8.8](i.8.8-type-safety-and-verification.md)).
 
 _[Rationale:_ For performance reasons items on the GC heap may not contain references to the interior of other GC objects, this motivates the restrictions on fields and boxing. Further returning a managed pointer which references a local or parameter variable may cause the reference to outlive the variable, hence it is not verifiable. _end rationale]_
 
 There are three value types in the Base Class Library (see [Partition IV - BCL](#todo-missing-hyperlink)): `System.TypedReference`, `System.RuntimeArgumentHandle`, and `System.ArgIterator`; which are treated specially by the CLI.
 
-The value type `System.TypedReference`, or **typed reference** or **typedref**, (§[I.8.2.2](i.8.2.2-built-in-value-and-reference-types.md), §[I.8.6.1.3](#todo-missing-hyperlink), §[I.12.4.1.5.3]) contains both a managed pointer to a location and a runtime representation of the type that can be stored at that location. Typed references have the same restrictions as byrefs. Typed references are created by the CIL instruction mkrefany (see [Partition III](#todo-missing-hyperlink)). The value types `System.RuntimeArgumentHandle` and `System.ArgIterator` (see [Partition IV](#todo-missing-hyperlink) and CIL instruction `arglist` in [Partition III](#todo-missing-hyperlink)), contain pointers into the VES stack. They can be used for local variable and parameter signatures. The use of these types for fields, method return types, the element type of an array, or in boxing is not verifiable (§[I.8.8](i.8.8-type-safety-and-verification.md)). These two types are referred to as **byref-like** types.
+The value type `System.TypedReference`, or **typed reference** or **typedref**, (§[I.8.2.2](i.8.2.2-built-in-value-and-reference-types.md), §[I.8.6.1.3](i.8.6.1.3-local-signatures.md), §[I.12.4.1.5.3]) contains both a managed pointer to a location and a runtime representation of the type that can be stored at that location. Typed references have the same restrictions as byrefs. Typed references are created by the CIL instruction mkrefany (see [Partition III](#todo-missing-hyperlink)). The value types `System.RuntimeArgumentHandle` and `System.ArgIterator` (see [Partition IV](#todo-missing-hyperlink) and CIL instruction `arglist` in [Partition III](#todo-missing-hyperlink)), contain pointers into the VES stack. They can be used for local variable and parameter signatures. The use of these types for fields, method return types, the element type of an array, or in boxing is not verifiable (§[I.8.8](i.8.8-type-safety-and-verification.md)). These two types are referred to as **byref-like** types.

docs/i.8.5.2-assemblies-and-scoping.md

@@ -40,7 +40,7 @@ The CTS supports an **enum** (also known as an **enumeration type**), an alterna
 
  * It shall not have any properties or events of its own. 
 
- * It shall not have any static fields unless they are literal. (see §[I.8.6.1.2](#todo-missing-hyperlink))
+ * It shall not have any static fields unless they are literal. (see §[I.8.6.1.2](i.8.6.1.2-location-signatures.md))
 
 The underlying type shall be a built-in integer type. Enums shall derive from `System.Enum`, hence they are value types. Like all value types, they shall be sealed (see §[I.8.9.9](i.8.9.9-object-type-inheritance.md)).
 

docs/i.8.6.1-signatures.md

@@ -1,6 +1,6 @@
 ## I.8.6.1 Signatures
 
-**Signatures** are the part of a contract that can be checked and automatically enforced. Signatures are formed by adding constraints to types and other signatures. A constraint is a limitation on the use of or allowed operations on a value or location. Example constraints would be whether a location can be overwritten with a different value or whether a value can ever be changed. All locations have signatures, as do all values. Assignment compatibility requires that the signature of the value, including constraints, be compatible with the signature of the location, including constraints. There are four fundamental kinds of signatures: type signatures (see §[I.8.6.1.1](i.8.6.1.1-type-signatures.md)), location signatures (see §[I.8.6.1.2](#todo-missing-hyperlink)), parameter signatures (see §[I.8.6.1.4](#todo-missing-hyperlink)), and method signatures (see §[I.8.6.1.5](#todo-missing-hyperlink)). (A fifth kind, a local signature (see §[I.8.6.1.3](#todo-missing-hyperlink)) is really a version of a location signature.)
+**Signatures** are the part of a contract that can be checked and automatically enforced. Signatures are formed by adding constraints to types and other signatures. A constraint is a limitation on the use of or allowed operations on a value or location. Example constraints would be whether a location can be overwritten with a different value or whether a value can ever be changed. All locations have signatures, as do all values. Assignment compatibility requires that the signature of the value, including constraints, be compatible with the signature of the location, including constraints. There are four fundamental kinds of signatures: type signatures (see §[I.8.6.1.1](i.8.6.1.1-type-signatures.md)), location signatures (see §[I.8.6.1.2](i.8.6.1.2-location-signatures.md)), parameter signatures (see §[I.8.6.1.4](i.8.6.1.4-paramater-signatures.md)), and method signatures (see §[I.8.6.1.5](i.8.6.1.5-method-signatures.md)). (A fifth kind, a local signature (see §[I.8.6.1.3](i.8.6.1.3-local-signatures.md)) is really a version of a location signature.)
 
 > #### CLS Rule 11:
 >

docs/i.8.7-assignment-compatibility.md

@@ -18,7 +18,7 @@ There are different rules for determining the compatibility of types, depending
 
 These relations are defined in terms of six type subsets:
 
-* *storage types* – these are the types that can occur as location (§[I.8.6.1.2](#todo-missing-hyperlink)), local (§[I.8.6.1.3](#todo-missing-hyperlink)) and parameter (§[I.8.6.1.4](#todo-missing-hyperlink)) signatures. _[Note:_ method signatures (§[I.8.6.1.5](#todo-missing-hyperlink)) are not included here as there are no method values which can be assigned, delegate types (§[I.8.9.3](i.8.9.3-delegates.md)) are reference types (§[I.8.2.1](i.8.2.1-value-types-and-reference-types.md)) and may occur in the above signatures. _end note]_
+* *storage types* – these are the types that can occur as location (§[I.8.6.1.2](i.8.6.1.2-location-signatures.md)), local (§[I.8.6.1.3](i.8.6.1.3-local-signatures.md)) and parameter (§[I.8.6.1.4](i.8.6.1.4-paramater-signatures.md)) signatures. _[Note:_ method signatures (§[I.8.6.1.5](i.8.6.1.5-method-signatures.md)) are not included here as there are no method values which can be assigned, delegate types (§[I.8.9.3](i.8.9.3-delegates.md)) are reference types (§[I.8.2.1](i.8.2.1-value-types-and-reference-types.md)) and may occur in the above signatures. _end note]_
 
  * *underlying types* – in the CTS enumerations are alternate names for existing types (§[I.8.5.2](i.8.5.2-assemblies-and-scoping.md)), termed their underlying type. Except for signature matching (§[I.8.5.2](i.8.5.2-assemblies-and-scoping.md)) enumerations are treated as their underlying type. This subset is the set of storage types with the enumerations removed.
 
@@ -150,12 +150,12 @@ _[Note:_ generic parameters are not reference types. Therefore, the compatibilit
 
 For the purpose of type compatibility when determining a type from a signature:
 
- 1. Any byref (`&`) constraint (§[I.8.6.1.3](#todo-missing-hyperlink)) is considered part of the type;
+ 1. Any byref (`&`) constraint (§[I.8.6.1.3](i.8.6.1.3-local-signatures.md)) is considered part of the type;
 
- 2. The special signature typed reference (§[I.8.6.1.3](#todo-missing-hyperlink)) is the type **typedref**;
+ 2. The special signature typed reference (§[I.8.6.1.3](i.8.6.1.3-local-signatures.md)) is the type **typedref**;
 
  3. Any **modopt**, **modreq**, or **pinned** modifiers are ignored; and
 
  4. Any calling convention is considered part of the type.
 
-_[Note:_ the literal constraint is not considered as fields so marked cannot be referenced from CIL (§[I.8.6.1.2](#todo-missing-hyperlink)). _end note]_
+_[Note:_ the literal constraint is not considered as fields so marked cannot be referenced from CIL (§[I.8.6.1.2](i.8.6.1.2-location-signatures.md)). _end note]_

docs/ii.15.4.5-vararg-methods.md

@@ -1,6 +1,6 @@
 ## II.15.4.5 vararg methods
 
-**vararg** methods accept a variable number of arguments. They shall use the **vararg** calling convention (§[II.15.3(#todo-missing-hyperlink)).
+**vararg** methods accept a variable number of arguments. They shall use the **vararg** calling convention (§[II.15.3](ii.15.3-calling-convention.md)).
 
 At each call site, a method reference shall be used to describe the types of the fixed and variable arguments that are passed. The fixed part of the argument list shall be separated from the additional arguments with an ellipsis (see [Partition I](#todo-missing-hyperlink)).
 

docs/iii.3.19-call.md

@@ -20,7 +20,7 @@ _[Rationale:_ This implements "call base class" behavior. _end rationale]_
 
 The arguments are placed on the stack in left-to-right order. That is, the first argument is computed and placed on the stack, then the second argument, and so on. There are three important special cases:
 
- 1. Calls to an instance (or virtual, see below) method shall push that instance reference (the *this* pointer) first. The signature carried in the metadata may not contain an entry in the parameter list for the *this* pointer but the calling convention always indicates whether one is required and if its signature is explicit or inferred (see §[I.8.6.1.5](#todo-missing-hyperlink) and §[II.15.3](ii.15.3-calling-convention.md)) _[Note:_ for calls to methods on value types, the *this* pointer is a managed pointer, not an instance reference §[I.8.6.1.5(#todo-missing-hyperlink). _end note]_
+ 1. Calls to an instance (or virtual, see below) method shall push that instance reference (the *this* pointer) first. The signature carried in the metadata may not contain an entry in the parameter list for the *this* pointer but the calling convention always indicates whether one is required and if its signature is explicit or inferred (see §[I.8.6.1.5](i.8.6.1.5-method-signatures.md) and §[II.15.3](ii.15.3-calling-convention.md)) _[Note:_ for calls to methods on value types, the *this* pointer is a managed pointer, not an instance reference §[I.8.6.1.5](i.8.6.1.5-method-signatures.md). _end note]_
 
  2. It is valid to call a virtual method using `call` (rather than `callvirt`); this indicates that the method is to be resolved using the class specified by method rather than as specified dynamically from the object being invoked. This is used, for example, to compile calls to "methods on super" (i.e., the statically known parent class).
 
@@ -46,7 +46,7 @@ For a typical use of the `call` instruction, verification checks that:
 
  1. _method_ refers to a valid `methodref`, `methoddef`, or `methodspec` token;
 
- 2. if _method_ requires a *this* pointer, as specified by its method signature (§[I.8.6.1.5](#todo-missing-hyperlink)), then one is one the stack and its verification type is *verifier-assignable-to* (§[III.1.8.1.2.3](iii.1.8.1.2.3-verification-type-compatibility.md)) the *this* signature of the method's signature;
+ 2. if _method_ requires a *this* pointer, as specified by its method signature (§[I.8.6.1.5](i.8.6.1.5-method-signatures.md)), then one is one the stack and its verification type is *verifier-assignable-to* (§[III.1.8.1.2.3](iii.1.8.1.2.3-verification-type-compatibility.md)) the *this* signature of the method's signature;
 
  3. the types of the arguments on the stack are *verifier-assignable-to* (§[III.1.8.1.2.3](iii.1.8.1.2.3-verification-type-compatibility.md)) the parameter signatures of the method's signature;
 

docs/iii.3.20-calli.md

@@ -18,7 +18,7 @@ The _ftn_ argument must be a method pointer to a method that can be legitimately
 
 The standalone signature specifies the number and type of parameters being passed, as well as the calling convention (See [Partition II](#todo-missing-hyperlink)) The calling convention is not checked dynamically, so code that uses a `calli` instruction will not work correctly if the destination does not actually use the specified calling convention.
 
-The arguments are placed on the stack in left-to-right order. That is, the first argument is computed and placed on the stack, then the second argument, and so on. The argument-building code sequence for an instance or virtual method shall push that instance reference (the *this* pointer, which shall not be null) first. _[Note:_ for calls to methods on value types, the *this* pointer is a managed pointer, not an instance reference. §[I.8.6.1.5](#todo-missing-hyperlink). _end note]_
+The arguments are placed on the stack in left-to-right order. That is, the first argument is computed and placed on the stack, then the second argument, and so on. The argument-building code sequence for an instance or virtual method shall push that instance reference (the *this* pointer, which shall not be null) first. _[Note:_ for calls to methods on value types, the *this* pointer is a managed pointer, not an instance reference. §[I.8.6.1.5](i.8.6.1.5-method-signatures.md). _end note]_
 
 The arguments are passed as though by implicit `starg` (§[III.3.61](iii.3.61-starg-length.md)) instructions, see _Implicit argument coercion_ §[III.1.6](iii.1.6-implicit-argument-coercion.md).
 

docs/iii.3.29-conv-ovf-to-type-un.md

@@ -35,4 +35,4 @@ Correct CIL has at least one value, of a type specified in [Table 8: Conversion
 
 #### Verifiability:
 
-The table [Table 8: Conversion Operations(#todo-missing-hyperlink) specifies a restricted set of types that are acceptable in verified code.
+The table [Table 8: Conversion Operations](#todo-missing-hyperlink) specifies a restricted set of types that are acceptable in verified code.

docs/iii.3.41-ldftn.md

@@ -28,6 +28,6 @@ Correct CIL requires that method is a valid `methoddef` or `methodref` token.
 
 #### Verifiability:
 
-Verification tracks the method signature (§[I.8.6.1.5](#todo-missing-hyperlink)) of the value, which includes the number and types of parameters, the type of the *this* pointer (for an instance method), and the return type and the calling convention. _[Note:_ the type of *this* pointer for an instance method is determined as described in §[I.8.6.1.5](#todo-missing-hyperlink) based on the resolved method definition. _end note]_
+Verification tracks the method signature (§[I.8.6.1.5](i.8.6.1.5-method-signatures.md)) of the value, which includes the number and types of parameters, the type of the *this* pointer (for an instance method), and the return type and the calling convention. _[Note:_ the type of *this* pointer for an instance method is determined as described in §[I.8.6.1.5](i.8.6.1.5-method-signatures.md) based on the resolved method definition. _end note]_
 
 See also the `newobj` instruction.