[llvm] r285133 - [docs] Fix a couple of typos in the new Error docs.

[Lang Hames via llvm-commits]

Author: lhames
Date: Tue Oct 25 17:22:48 2016
New Revision: 285133

URL: http://llvm.org/viewvc/llvm-project?rev=285133&view=rev
Log:
[docs] Fix a couple of typos in the new Error docs.

Modified:
    llvm/trunk/docs/ProgrammersManual.rst

Modified: llvm/trunk/docs/ProgrammersManual.rst
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/ProgrammersManual.rst?rev=285133&r1=285132&r2=285133&view=diff
==============================================================================
--- llvm/trunk/docs/ProgrammersManual.rst (original)
+++ llvm/trunk/docs/ProgrammersManual.rst Tue Oct 25 17:22:48 2016
@@ -504,7 +504,7 @@ StringError
 Many kinds of errors have no recovery strategy, the only action that can be
 taken is to report them to the user so that the user can attempt to fix the
 environment. In this case representing the error as a string makes perfect
-sense. LLVM provides the ``StringError class for this purpose. It takes two
+sense. LLVM provides the ``StringError`` class for this purpose. It takes two
 arguments: A string error message, and an equivalent ``std::error_code`` for
 interoperability:
 
@@ -582,7 +582,7 @@ Using ExitOnError to simplify tool code
 """""""""""""""""""""""""""""""""""""""
 
 Library code should never call ``exit`` for a recoverable error, however in tool
-code (especially comamnd line tools) this can be a reasonable approach. Calling
+code (especially command line tools) this can be a reasonable approach. Calling
 ``exit`` upon encountering an error dramatically simplifies control flow as the
 error no longer needs to be propagated up the stack. This allows code to be
 written in straight-line style, as long as each fallible call is wrapped in a