[Kaleidoscope] Tiny typo fixes

[robin850]

Summary

Hello,

Just fixes for "lets" references which should certainly be "let's" in the Kaleidoscope tutorial.

Off topic : just wanted to say thank you for this amazing piece of software and the really great documentation ! <3

Have a nice day !

[SjoerdMeijer]

Looks good to me.
Just checking, do you have commit access?

[robin850]

No, I don't have commit access at all 😊

[SjoerdMeijer]

Then the obvious next question is: do you want me to commit it on your behalf?

[robin850]

Yeah, why not ! :-) (If it's not too time consuming for you, obviously)

[SjoerdMeijer]

Done: see message/link above. Thanks.

llvm/trunk/docs/tutorial/LangImpl02.rst

 language. Once we have a parser, we'll define and build an `Abstract
 Syntax Tree <http://en.wikipedia.org/wiki/Abstract_syntax_tree>`_ (AST).
 
 The parser we will build uses a combination of `Recursive Descent
 Parsing <http://en.wikipedia.org/wiki/Recursive_descent_parser>`_ and
 `Operator-Precedence
 Parsing <http://en.wikipedia.org/wiki/Operator-precedence_parser>`_ to
 parse the Kaleidoscope language (the latter for binary expressions and
-the former for everything else). Before we get to parsing though, lets
+the former for everything else). Before we get to parsing though, let's
 talk about the output of the parser: the Abstract Syntax Tree.
 
 The Abstract Syntax Tree (AST)
 ==============================
 
 The AST for a program captures its behavior in such a way that it is
 easy for later stages of the compiler (e.g. code generation) to
 interpret. We basically want one object for each construct in the

 There is a lot of room for extension here. You can define new AST nodes,
 extend the language in many ways, etc. In the `next
 installment <LangImpl03.html>`_, we will describe how to generate LLVM
 Intermediate Representation (IR) from the AST.
 
 Full Code Listing
 =================
 
-Here is the complete code listing for our running example. Because this 
+Here is the complete code listing for our running example. Because this
 uses the LLVM libraries, we need to link them in. To do this, we use the
 `llvm-config <http://llvm.org/cmds/llvm-config.html>`_ tool to inform
 our makefile/command line about which options to use:
 
 .. code-block:: bash
 
     # Compile
     clang++ -g -O3 toy.cpp `llvm-config --cxxflags`

llvm/trunk/docs/tutorial/LangImpl03.rst

 our basic framework.
 
 Function Code Generation
 ========================
 
 Code generation for prototypes and functions must handle a number of
 details, which make their code less beautiful than expression code
 generation, but allows us to illustrate some important points. First,
-lets talk about code generation for prototypes: they are used both for
+let's talk about code generation for prototypes: they are used both for
 function bodies and external function declarations. The code starts
 with:
 
 .. code-block:: c++
 
     Function *PrototypeAST::codegen() {
       // Make the function type:  double(double,double) etc.
       std::vector<Type*> Doubles(Args.size(),

llvm/trunk/docs/tutorial/LangImpl04.rst

 LLVM provides a wide variety of optimizations that can be used in
 certain circumstances. Some `documentation about the various
 passes <../Passes.html>`_ is available, but it isn't very complete.
 Another good source of ideas can come from looking at the passes that
 ``Clang`` runs to get started. The "``opt``" tool allows you to
 experiment with passes from the command line, so you can see if they do
 anything.
 
-Now that we have reasonable code coming out of our front-end, lets talk
+Now that we have reasonable code coming out of our front-end, let's talk
 about executing it!
 
 Adding a JIT Compiler
 =====================
 
 Code that is available in LLVM IR can have a wide variety of tools
 applied to it. For example, you can run optimizations on it (as we did
 above), you can dump it out in textual or binary forms, you can compile

 application.
 
 Finally, since we don't support re-evaluation of top-level expressions, we
 remove the module from the JIT when we're done to free the associated memory.
 Recall, however, that the module we created a few lines earlier (via
 ``InitializeModuleAndPassManager``) is still open and waiting for new code to be
 added.
 
-With just these two changes, lets see how Kaleidoscope works now!
+With just these two changes, let's see how Kaleidoscope works now!
 
 ::
 
     ready> 4+5;
     Read top-level expression:
     define double @0() {
     entry:
       ret double 9.000000e+00
static void HandleExtern() {
         getNextToken();
       }
     }
 
 In HandleDefinition, we add two lines to transfer the newly defined function to
 the JIT and open a new module. In HandleExtern, we just need to add one line to
 add the prototype to FunctionProtos.
 
-With these changes made, lets try our REPL again (I removed the dump of the
+With these changes made, let's try our REPL again (I removed the dump of the
 anonymous functions this time, you should get the idea by now :) :
 
 ::
 
     ready> def foo(x) x + 1;
     ready> foo(2);
     Evaluated to 3.000000
 

llvm/trunk/docs/tutorial/LangImpl05.rst

 ============
 
 Extending Kaleidoscope to support if/then/else is quite straightforward.
 It basically requires adding support for this "new" concept to the
 lexer, parser, AST, and LLVM code emitter. This example is nice, because
 it shows how easy it is to "grow" a language over time, incrementally
 extending it as new ideas are discovered.
 
-Before we get going on "how" we add this extension, lets talk about
+Before we get going on "how" we add this extension, let's talk about
 "what" we want. The basic idea is that we want to be able to write this
 sort of thing:
 
 ::
 
     def fib(x)
       if x < 3 then
         1

 The semantics of the if/then/else expression is that it evaluates the
 condition to a boolean equality value: 0.0 is considered to be false and
 everything else is considered to be true. If the condition is true, the
 first subexpression is evaluated and returned, if the condition is
 false, the second subexpression is evaluated and returned. Since
 Kaleidoscope allows side-effects, this behavior is important to nail
 down.
 
-Now that we know what we "want", lets break this down into its
+Now that we know what we "want", let's break this down into its
 constituent pieces.
 
 Lexer Extensions for If/Then/Else
 ---------------------------------
 
 The lexer extensions are straightforward. First we add new enum values
 for the relevant tokens:
 

 ------------------------
 
 Now that we have it parsing and building the AST, the final piece is
 adding LLVM code generation support. This is the most interesting part
 of the if/then/else example, because this is where it starts to
 introduce new concepts. All of the code above has been thoroughly
 described in previous chapters.
 
-To motivate the code we want to produce, lets take a look at a simple
+To motivate the code we want to produce, let's take a look at a simple
 example. Consider:
 
 ::
 
     extern foo();
     extern bar();
     def baz(x) if x then foo() else bar();
 

 
 In `Chapter 7 <LangImpl07.html>`_ of this tutorial ("mutable variables"),
 we'll talk about #1 in depth. For now, just believe me that you don't
 need SSA construction to handle this case. For #2, you have the choice
 of using the techniques that we will describe for #1, or you can insert
 Phi nodes directly, if convenient. In this case, it is really
 easy to generate the Phi node, so we choose to do it directly.
 
-Okay, enough of the motivation and overview, lets generate code!
+Okay, enough of the motivation and overview, let's generate code!
 
 Code Generation for If/Then/Else
 --------------------------------
 
 In order to generate code for this, we implement the ``codegen`` method
 for ``IfExprAST``:
 
 .. code-block:: c++

 language that can calculate a wide variety of numeric functions. Next up
 we'll add another useful expression that is familiar from non-functional
 languages...
 
 'for' Loop Expression
 =====================
 
 Now that we know how to add basic control flow constructs to the
-language, we have the tools to add more powerful things. Lets add
+language, we have the tools to add more powerful things. Let's add
 something more aggressive, a 'for' expression:
 
 ::
 
      extern putchard(char);
      def printstar(n)
        for i = 1, i < n, 1.0 in
          putchard(42);  # ascii 42 = '*'
 
      # print 100 '*' characters
      printstar(100);
 
 This expression defines a new variable ("i" in this case) which iterates
 from a starting value, while the condition ("i < n" in this case) is
 true, incrementing by an optional step value ("1.0" in this case). If
 the step value is omitted, it defaults to 1.0. While the loop is true,
 it executes its body expression. Because we don't have anything better
 to return, we'll just define the loop as always returning 0.0. In the
 future when we have mutable variables, it will get more useful.
 
-As before, lets talk about the changes that we need to Kaleidoscope to
+As before, let's talk about the changes that we need to Kaleidoscope to
 support this.
 
 Lexer Extensions for the 'for' Loop
 -----------------------------------
 
 The lexer extensions are the same sort of thing as for if/then/else:
 
 .. code-block:: c++
loop:       ; preds = %loop, %entry
       br i1 %loopcond, label %loop, label %afterloop
 
     afterloop:      ; preds = %loop
       ; loop always returns 0.0
       ret double 0.000000e+00
     }
 
 This loop contains all the same constructs we saw before: a phi node,
-several expressions, and some basic blocks. Lets see how this fits
+several expressions, and some basic blocks. Let's see how this fits
 together.
 
 Code Generation for the 'for' Loop
 ----------------------------------
 
 The first part of codegen is very simple: we just output the start
 expression for the loop value:
 

llvm/trunk/docs/tutorial/LangImpl06.rst

 operator, we register it in the precedence table. This allows the binary
 operator parsing logic we already have in place to handle it. Since we
 are working on a fully-general operator precedence parser, this is all
 we need to do to "extend the grammar".
 
 Now we have useful user-defined binary operators. This builds a lot on
 the previous framework we built for other operators. Adding unary
 operators is a bit more challenging, because we don't have any framework
-for it yet - lets see what it takes.
+for it yet - let's see what it takes.
 
 User-defined Unary Operators
 ============================
 
 Since we don't currently support unary operators in the Kaleidoscope
 language, we'll need to add everything to support them. Above, we added
 simple support for the 'unary' keyword to the lexer. In addition to
 that, we need an AST node: