mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2024-12-14 15:19:33 +00:00
Fix some typos.
llvm-svn: 43709
This commit is contained in:
parent
994c6b5308
commit
da09f937ef
@ -66,7 +66,7 @@ fib(40)
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>We also allow Kaleidoscope to call into standard library functions (this LLVM
|
||||
<p>We also allow Kaleidoscope to call into standard library functions (the LLVM
|
||||
JIT makes this completely trivial). This means that you can use the 'extern'
|
||||
keyword to define a function before you use it (this is also useful for mutually
|
||||
recursive functions). For example:</p>
|
||||
@ -90,7 +90,7 @@ eventually add side effects for those who prefer them.</p>
|
||||
<p>In order to make this tutorial
|
||||
maximally understandable and hackable, we choose to implement everything in C++
|
||||
instead of using lexer and parser generators. LLVM obviously works just fine
|
||||
with these tools, and choice of these tools doesn't impact overall design.</p>
|
||||
with such tools, and making use of them doesn't impact the overall design.</p>
|
||||
|
||||
<p>A note about this tutorial: we expect you to extend the language and play
|
||||
with it on your own. Take the code and go crazy hacking away at it. It can be
|
||||
@ -203,7 +203,7 @@ handle them here inline. Numeric values are similar:</p>
|
||||
<p>This is all pretty straight-forward code for processing input. When reading
|
||||
a numeric value from input, we use the C <tt>strtod</tt> function to convert it
|
||||
to a numeric value that we store in <tt>NumVal</tt>. Note that this isn't doing
|
||||
sufficient error checking: it will incorrect read "1.23.45.67" and handle it as
|
||||
sufficient error checking: it will incorrectly read "1.23.45.67" and handle it as
|
||||
if you typed in "1.23". Feel free to extend it :). Next we handle comments:
|
||||
</p>
|
||||
|
||||
@ -220,9 +220,9 @@ if you typed in "1.23". Feel free to extend it :). Next we handle comments:
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>We handle comments by skipping to the end of the line and then returnning the
|
||||
<p>We handle comments by skipping to the end of the line and then returning the
|
||||
next comment. Finally, if the input doesn't match one of the above cases, it is
|
||||
either an operator character like '+', the end of file. These are handled with
|
||||
either an operator character like '+' or the end of the file. These are handled with
|
||||
this code:</p>
|
||||
|
||||
<div class="doc_code">
|
||||
|
@ -212,7 +212,7 @@ FunctionAST *ErrorF(const char *Str) { Error(Str); return 0; }
|
||||
<p>
|
||||
The <tt>Error</tt> routines are simple helper routines that our parser will use
|
||||
to handle errors. The error recovery in our parser will not be the best and
|
||||
are not particular user-friendly, but it will be enough for our tutorial. These
|
||||
is not particular user-friendly, but it will be enough for our tutorial. These
|
||||
routines make it easier to handle errors in routines that have various return
|
||||
types: they always return null.</p>
|
||||
|
||||
@ -284,7 +284,7 @@ return null on an error.</p>
|
||||
calling <tt>ParseExpression</tt> (we will soon see that <tt>ParseExpression</tt> can call
|
||||
<tt>ParseParenExpr</tt>). This is powerful because it allows us to handle
|
||||
recursive grammars, and keeps each production very simple. Note that
|
||||
parenthesis do not cause construction of AST nodes themselves. While we could
|
||||
parentheses do not cause construction of AST nodes themselves. While we could
|
||||
do this, the most important role of parens are to guide the parser and provide
|
||||
grouping. Once the parser constructs the AST, parens are not needed.</p>
|
||||
|
||||
@ -432,7 +432,7 @@ the expression "a+b+(c+d)*e*f+g". Operator precedence parsing considers this
|
||||
as a stream of primary expressions separated by binary operators. As such,
|
||||
it will first parse the leading primary expression "a", then it will see the
|
||||
pairs [+, b] [+, (c+d)] [*, e] [*, f] and [+, g]. Note that because parentheses
|
||||
are primary expressions that the binary expression parser doesn't need to worry
|
||||
are primary expressions, the binary expression parser doesn't need to worry
|
||||
about nested subexpressions like (c+d) at all.
|
||||
</p>
|
||||
|
||||
@ -631,7 +631,7 @@ static PrototypeAST *ParsePrototype() {
|
||||
</div>
|
||||
|
||||
<p>Given this, a function definition is very simple, just a prototype plus
|
||||
and expression to implement the body:</p>
|
||||
an expression to implement the body:</p>
|
||||
|
||||
<div class="doc_code">
|
||||
<pre>
|
||||
|
Loading…
Reference in New Issue
Block a user