Fix a few typos

This commit is contained in:
Mark Mansi 2018-03-11 21:05:29 -05:00
parent 5dfe4f26c5
commit ce45556483
1 changed files with 10 additions and 10 deletions

View File

@ -79,19 +79,19 @@ might produce the answer:
After all, `Rc<?T>` is true **no matter what type `?T` is**. After all, `Rc<?T>` is true **no matter what type `?T` is**.
<a name="query-response">
## A trait query in rustc ## A trait query in rustc
The trait queries in rustc work somewhat differently. Instead of The trait queries in rustc work somewhat differently. Instead of
trying to enumerate **all possible** answers for you, they are looking trying to enumerate **all possible** answers for you, they are looking
for an **unambiguous** answer. In particular, when they tells you the for an **unambiguous** answer. In particular, when they tell you the
value for a type variable, that means that this is the **only possible value for a type variable, that means that this is the **only possible
instantiation** that you could use, given the current set of impls and instantiation** that you could use, given the current set of impls and
where-clauses, that would be provable. (Internally within the solver, where-clauses, that would be provable. (Internally within the solver,
though, they can potentially enumerate all possible answers. See though, they can potentially enumerate all possible answers. See
[the description of the SLG solver](./traits-slg.html) for details.) [the description of the SLG solver](./traits-slg.html) for details.)
<a name=query-response>
The response to a trait query in rustc is typically a The response to a trait query in rustc is typically a
`Result<QueryResult<T>, NoSolution>` (where the `T` will vary a bit `Result<QueryResult<T>, NoSolution>` (where the `T` will vary a bit
depending on the query itself). The `Err(NoSolution)` case indicates depending on the query itself). The `Err(NoSolution)` case indicates
@ -206,7 +206,7 @@ vector. This in turn implies that `?U` is [unified] to `Vec<?V>`.
Let's suppose that the type checker decides to revisit the Let's suppose that the type checker decides to revisit the
"as-yet-unproven" trait obligation we saw before, `Vec<?T>: "as-yet-unproven" trait obligation we saw before, `Vec<?T>:
Borrow<?U>`. `?U` is no longer an unbound inference variable; it now Borrow<?U>`. `?U` is no longer an unbound inference variable; it now
has a value, &. So, if we "refresh" the query with that value, we get: has a value, `Vec<?V>`. So, if we "refresh" the query with that value, we get:
Vec<?T>: Borrow<Vec<?V>> Vec<?T>: Borrow<Vec<?V>>