]> granicus.if.org Git - llvm/commitdiff
[docs] Fix a couple of typos in the new Error docs.
authorLang Hames <lhames@gmail.com>
Tue, 25 Oct 2016 22:22:48 +0000 (22:22 +0000)
committerLang Hames <lhames@gmail.com>
Tue, 25 Oct 2016 22:22:48 +0000 (22:22 +0000)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@285133 91177308-0d34-0410-b5e6-96231b3b80d8

docs/ProgrammersManual.rst

index cc6d3f84d5560b8ef6183fbfcc862bd6b7bf81e0..d970f1af04e1e3bb8cb7025e532b577b946dd439 100644 (file)
@@ -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