Index: docs/CoverageMappingFormat.rst
===================================================================
--- docs/CoverageMappingFormat.rst
+++ docs/CoverageMappingFormat.rst
@@ -21,7 +21,7 @@
 guided optimization works is useful, but not required.
 
 We start by showing how to use LLVM and Clang for code coverage analysis,
-then we briefly desribe LLVM's code coverage mapping format and the
+then we briefly describe LLVM's code coverage mapping format and the
 way that Clang and LLVM's code coverage tool work with this format. After
 the basics are down, more advanced features of the coverage mapping format
 are discussed - such as the data structures, LLVM IR representation and
@@ -99,7 +99,7 @@
 
 The function's coverage mapping data contains an array of mapping regions.
 A mapping region stores the `source code range`_ that is covered by this region,
-the `file id <coverage file id_>`_, the `coverage mapping counter`_ and
+the `file id`_, the `coverage mapping counter`_ and
 the region's kind.
 There are several kinds of mapping regions:
 
@@ -158,12 +158,12 @@
 The source range record contains the starting and ending location of a certain
 mapping region. Both locations include the line and the column numbers.
 
-.. _coverage file id:
+.. _file id:
 
 File ID:
 ^^^^^^^^
 
-The file id an integer value that tells us
+The file id is an integer value that tells us
 in which source file or macro expansion is this region located.
 It enables Clang to produce mapping information for the code
 defined inside macros, like this example demonstrates:
@@ -351,7 +351,7 @@
   | ``0x01`` | The number of mapping regions that are stored in an array for the function's file id #0.                                |
   +----------+-------------------------------------------------------------------------------------------------------------------------+
   | ``0x01`` | The coverage mapping counter for the first region in this function. The value of 1 tells us that it's a coverage        |
-  |          | mapping counter that is a reference ot the profile instrumentation counter with an index of 0.                          |
+  |          | mapping counter that is a reference to the profile instrumentation counter with an index of 0.                          |
   +----------+-------------------------------------------------------------------------------------------------------------------------+
   | ``0x01`` | The starting line of the first mapping region in this function.                                                         |
   +----------+-------------------------------------------------------------------------------------------------------------------------+
@@ -373,8 +373,8 @@
 ========
 
 The per-function coverage mapping data is encoded as a stream of bytes,
-with a simple structure. The structure consists of the encoding
-`types <cvmtypes_>`_ like variable-length unsigned integers, that
+with a simple structure. The structure consists of the `encoding
+types`_ like variable-length unsigned integers, that
 are used to encode `File ID Mapping`_, `Counter Expressions`_ and
 the `Mapping Regions`_.
 
@@ -382,13 +382,13 @@
 
   ``[file id mapping, counter expressions, mapping regions]``
 
-The translation unit filenames are encoded using the same encoding
-`types <cvmtypes_>`_ as the per-function coverage mapping data, with the
+The translation unit filenames are encoded using the same `encoding
+types`_ as the per-function coverage mapping data, with the
 following structure:
 
   ``[numFilenames : LEB128, filename0 : string, filename1 : string, ...]``
 
-.. _cvmtypes:
+.. _encoding types:
 
 Types
 -----
@@ -396,12 +396,12 @@
 This section describes the basic types that are used by the encoding format
 and can appear after ``:`` in the ``[foo : type]`` description.
 
-.. _LEB128:
+.. _LEB value:
 
 LEB128
 ^^^^^^
 
-LEB128 is an unsigned interger value that is encoded using DWARF's LEB128
+LEB128 is an unsigned integer value that is encoded using DWARF's LEB128
 encoding, optimizing for the case where values are small
 (1 byte for values less than 128).
 
@@ -412,7 +412,7 @@
 
 ``[length : LEB128, characters...]``
 
-String values are encoded with a `LEB value <LEB128_>`_ for the length
+String values are encoded with a `LEB value`_ for the length
 of the string and a sequence of bytes for its characters.
 
 .. _file id mapping:
@@ -430,12 +430,12 @@
 
 ``[value : LEB128]``
 
-A `coverage mapping counter`_ is stored in a single `LEB value <LEB128_>`_.
-It is composed of two things --- the `tag <counter-tag_>`_
+A `coverage mapping counter`_ is stored in a single `LEB value`_.
+It is composed of two things --- the `counter tag`
 which is stored in the lowest 2 bits, and the `counter data`_ which is stored
 in the remaining bits.
 
-.. _counter-tag:
+.. _counter tag:
 
 Tag:
 ^^^^
@@ -473,7 +473,7 @@
 
 Counter expressions consist of two counters as they
 represent binary arithmetic operations.
-The expression's kind is determined from the `tag <counter-tag_>`_ of the
+The expression's kind is determined from the `counter tag`_ of the
 counter that references this expression.
 
 .. _Mapping Regions:
@@ -536,7 +536,7 @@
 
 ``[value : LEB128]``
 
-A pseudo-counter is stored in a single `LEB value <LEB128_>`_, just like
+A pseudo-counter is stored in a single `LEB value`_, just like
 the ordinary counter. It has the following interpretation:
 
 * bits 0-1: tag, which is always 0.