fix some typos in the doc

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292014 91177308-0d34-0410-b5e6-96231b3b80d8

diff --git a/docs/AMDGPUUsage.rst b/docs/AMDGPUUsage.rst
index 0824eb86650aea1cef4811faff88e04359cec918..2c1a22762bce0556ceb051a400b85da50b3ec77c 100644 (file)
--- a/docs/AMDGPUUsage.rst
+++ b/docs/AMDGPUUsage.rst
@@ -204,7 +204,7 @@ SOPP Instruction Examples
 For full list of supported instructions, refer to "SOPP Instructions" in ISA Manual.
 
 Unless otherwise mentioned, little verification is performed on the operands
-of SOPP Instrucitons, so it is up to the programmer to be familiar with the
+of SOPP Instructions, so it is up to the programmer to be familiar with the
 range or acceptable values.
 
 Vector ALU Instruction Examples

diff --git a/docs/CoverageMappingFormat.rst b/docs/CoverageMappingFormat.rst
index f4dcfda5bdacda25c8e86c3187f680a9616922bd..46cc9d10f3195b09a92d3ff694da946a32277b41 100644 (file)
--- a/docs/CoverageMappingFormat.rst
+++ b/docs/CoverageMappingFormat.rst
@@ -21,7 +21,7 @@ to know how it works under the hood. A prior knowledge of how Clang's profile
 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

diff --git a/docs/GettingStarted.rst b/docs/GettingStarted.rst
index 66f4b8c627a381c6a33e08b4b0626d90d4c6ba00..6811c5d1e98cc963989d1e2e83bc3f4bd5c20c6d 100644 (file)
--- a/docs/GettingStarted.rst
+++ b/docs/GettingStarted.rst
@@ -738,7 +738,7 @@ to your path, you can push committed changes upstream with `git llvm push`.
 While this is using SVN under the hood, it does not require any interaction from
 you with git-svn.
 After a few minutes, `git pull` should get back the changes as they were
-commited. Note that a current limitation is that `git` does not directly record
+committed. Note that a current limitation is that `git` does not directly record
 file rename, and thus it is propagated to SVN as a combination of delete-add
 instead of a file rename.
 

diff --git a/docs/ProgrammersManual.rst b/docs/ProgrammersManual.rst
index ffc022eef168d8f96e0006125b140cda93f29958..1c96046bf40a7b41c266626cd5abcbd4fcace7d5 100644 (file)
--- a/docs/ProgrammersManual.rst
+++ b/docs/ProgrammersManual.rst
@@ -864,7 +864,7 @@ completing the walk over the archive they could use the ``joinErrors`` utility:
 
 The ``joinErrors`` routine builds a special error type called ``ErrorList``,
 which holds a list of user defined errors. The ``handleErrors`` routine
-recognizes this type and will attempt to handle each of the contained erorrs in
+recognizes this type and will attempt to handle each of the contained errors in
 order. If all contained errors can be handled, ``handleErrors`` will return
 ``Error::success()``, otherwise ``handleErrors`` will concatenate the remaining
 errors and return the resulting ``ErrorList``.

diff --git a/docs/Proposals/GitHubMove.rst b/docs/Proposals/GitHubMove.rst
index c1bdfb359289214d3d1a2e75c6f34087b273e136..f12077504dba0e6253523a38541e36bdba0c581f 100644 (file)
--- a/docs/Proposals/GitHubMove.rst
+++ b/docs/Proposals/GitHubMove.rst
@@ -30,7 +30,7 @@ This proposal relates only to moving the hosting of our source-code repository
 from SVN hosted on our own servers to Git hosted on GitHub. We are not proposing
 using GitHub's issue tracker, pull-requests, or code-review.
 
-Contributers will continue to earn commit access on demand under the Developer
+Contributors will continue to earn commit access on demand under the Developer
 Policy, except that that a GitHub account will be required instead of SVN
 username/password-hash.
 
@@ -433,7 +433,7 @@ Concerns
  * Using the monolithic repository may add overhead for those *integrating* a
    standalone sub-project, even if they aren't contributing to it, due to the
    same disk space concern as the point above. The availability of the
-   sub-project Git mirror addesses this, even without SVN access.
+   sub-project Git mirror addresses this, even without SVN access.
  * Preservation of the existing read/write SVN-based workflows relies on the
    GitHub SVN bridge, which is an extra dependency.  Maintaining this locks us
    into GitHub and could restrict future workflow changes.

diff --git a/docs/TestingGuide.rst b/docs/TestingGuide.rst
index 5dac58309e45ae201e2e360eb96c684b46fc0b90..26143febd07397845c478883617ef1eb181614da 100644 (file)
--- a/docs/TestingGuide.rst
+++ b/docs/TestingGuide.rst
@@ -313,7 +313,7 @@ default outputs a ``ModuleID``:
       ret i32 0
   }
 
-``ModuleID`` can unexpetedly match against ``CHECK`` lines.  For example:
+``ModuleID`` can unexpectedly match against ``CHECK`` lines.  For example:
 
 .. code-block:: llvm
 

diff --git a/docs/WritingAnLLVMBackend.rst b/docs/WritingAnLLVMBackend.rst
index f06a95da215229a883454416f06a5675927d034f..0fc7382f788bbb418b5ff80c07b041378ed3df81 100644 (file)
--- a/docs/WritingAnLLVMBackend.rst
+++ b/docs/WritingAnLLVMBackend.rst
@@ -593,12 +593,12 @@ the order in the definition of ``IntRegs`` in the target description file.
     FPRegsClass     FPRegsRegClass;
     IntRegsClass    IntRegsRegClass;
   ...
-    // IntRegs Sub-register Classess...
+    // IntRegs Sub-register Classes...
     static const TargetRegisterClass* const IntRegsSubRegClasses [] = {
       NULL
     };
   ...
-    // IntRegs Super-register Classess...
+    // IntRegs Super-register Classes..
     static const TargetRegisterClass* const IntRegsSuperRegClasses [] = {
       NULL
     };

diff --git a/docs/YamlIO.rst b/docs/YamlIO.rst
index 04e63fac6a4ba07efe4d9a3b6ed8eb790f91215a..0b728ed8ec1e6ccedb0ab769e9a02a05523a3bde 100644 (file)
--- a/docs/YamlIO.rst
+++ b/docs/YamlIO.rst
@@ -731,7 +731,7 @@ it is parsed. This allows dynamic types of nodes.  But the YAML I/O model uses
 static typing, so there are limits to how you can use tags with the YAML I/O
 model. Recently, we added support to YAML I/O for checking/setting the optional 
 tag on a map. Using this functionality it is even possbile to support different 
-mappings, as long as they are convertable.  
+mappings, as long as they are convertible.  
 
 To check a tag, inside your mapping() method you can use io.mapTag() to specify
 what the tag should be.  This will also add that tag when writing yaml.