Ch. 17: Fix spelling and internal links

ci/dictionary.txt

@@ -152,6 +152,7 @@ ebook
 ebooks
 Edsger
 egular
+ElementRef
 else's
 emoji
 encodings
@@ -191,6 +192,8 @@ FrenchToast
 FromIterator
 FromResidual
 frontend
+FuturesUnordered
+GetAwaitPoint
 getrandom
 getter
 getters
@@ -248,6 +251,7 @@ internet
 interoperate
 IntoFuture
 IntoIterator
+intra
 InvalidDigit
 invariants
 ioerror
@@ -295,6 +299,7 @@ lval
 macOS
 Matsakis
 mathematic
+mdbook
 memoization
 metadata
 Metadata
@@ -370,6 +375,7 @@ OurError
 OutlinePrint
 overloadable
 overread
+PageTitleFuture
 PanicPayload
 parallelizable
 param
@@ -521,6 +527,7 @@ TcpListener
 TcpStream
 templating
 test's
+TextAwaitPoint
 TextField
 That'd
 there'd

src/ch17-02-concurrency-with-async.md

@@ -152,7 +152,7 @@ what we saw with threads. That is because the `trpl::join` function is *fair*,
 meaning it checks each future equally often, alternating between them, and never
 lets one race ahead if the other is ready. With threads, the operating system
 decides which thread to check and how long to let it run. With async Rust, the
-runtime decides which taks to check. (In practice, the details get complicated
+runtime decides which task to check. (In practice, the details get complicated
 because an async runtime might use operating system threads under the hood as
 part of how it manages concurrency, so guaranteeing fairness can be more work
 for a runtime—but it is still possible!) Runtimes do not have to guarantee

src/ch17-05-traits-for-async.md

@@ -11,9 +11,9 @@ still leaving the *really* deep dive for other documentation!
 
 ### Future
 
-Back in [Async Functions][async-functions], we noted that `Future` is a trait.
-Let’s start by taking a closer look at how it works. Here is how Rust defines
-a `Future`:
+Back in [Futures and the Async Syntax][futures-syntax], we noted that `Future`
+is a trait. Let’s start by taking a closer look at how it works. Here is how
+Rust defines a `Future`:
 
 ```rust
 use std::pin::Pin;
@@ -199,7 +199,7 @@ starts to explain the error message we saw above—but that was in terms of
 `Unpin`, not `Pin`. So what exactly are `Pin` and `Unpin`, how do they relate,
 and why does `Future` need `self` to be in a `Pin` type to call `poll`?
 
-In [“What Are Futures”][what-are-futures], we described how a series of await
+In [Our First Async Program][first-async], we described how a series of await
 points in a future get compiled into a state machine—and noted how the compiler
 helps make sure that state machine follows all of Rust’s normal rules around
 safety, including borrowing and ownership. To make that work, Rust looks at what
@@ -379,10 +379,12 @@ even when you need to write your own streaming data type, you *only* have to
 implement `Stream`, and then anyone who uses your data type can use `StreamExt`
 and its methods with it automatically.
 
+[futures-syntax]: /ch17-01-futures-and-syntax.md
 [counting]: /ch17-02-concurrency-with-async.md
 [async-book]: https://rust-lang.github.io/async-book/
 [under-the-hood]: https://rust-lang.github.io/async-book/02_execution/01_chapter.html
 [pinning]: https://rust-lang.github.io/async-book/04_pinning/01_chapter.html
+[first-async]: /ch17-01-futures-and-syntax.md#our-first-async-program
 
 That’s all we’re going to cover for the lower-level details on these traits. To
 wrap up, let’s consider how futures (including streams), tasks, and threads all