Skip to content

Commit ce45556

Browse files
committed
Fix a few typos
1 parent 5dfe4f2 commit ce45556

File tree

1 file changed

+10
-10
lines changed

1 file changed

+10
-10
lines changed

src/traits-canonical-queries.md

Lines changed: 10 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -20,7 +20,7 @@ will run off and start supplying you with every possible answer it can
2020
find. So given something like this:
2121

2222
?- Vec<i32>: AsRef<?U>
23-
23+
2424
The solver might answer:
2525

2626
Vec<i32>: AsRef<[i32]>
@@ -71,27 +71,27 @@ Another interesting thing is that queries might still have variables
7171
in them. For example:
7272

7373
?- Rc<?T>: Clone
74-
74+
7575
might produce the answer:
7676

7777
Rc<?T>: Clone
7878
continue? (y/n)
79-
80-
After all, `Rc<?T>` is true **no matter what type `?T` is**.
79+
80+
After all, `Rc<?T>` is true **no matter what type `?T` is**.
81+
82+
<a name="query-response">
8183

8284
## A trait query in rustc
8385

8486
The trait queries in rustc work somewhat differently. Instead of
8587
trying to enumerate **all possible** answers for you, they are looking
86-
for an **unambiguous** answer. In particular, when they tells you the
88+
for an **unambiguous** answer. In particular, when they tell you the
8789
value for a type variable, that means that this is the **only possible
8890
instantiation** that you could use, given the current set of impls and
8991
where-clauses, that would be provable. (Internally within the solver,
9092
though, they can potentially enumerate all possible answers. See
9193
[the description of the SLG solver](./traits-slg.html) for details.)
9294

93-
<a name=query-response>
94-
9595
The response to a trait query in rustc is typically a
9696
`Result<QueryResult<T>, NoSolution>` (where the `T` will vary a bit
9797
depending on the query itself). The `Err(NoSolution)` case indicates
@@ -191,7 +191,7 @@ fn main() {
191191
let mut t: Vec<_> = vec![]; // Type: Vec<?T>
192192
let mut u: Option<_> = None; // Type: Option<?U>
193193
foo(t, u); // `Vec<?T>: Borrow<?U>` => ambiguous
194-
194+
195195
// New stuff:
196196
u = Some(vec![]); // ?U = Vec<?V>
197197
}
@@ -206,10 +206,10 @@ vector. This in turn implies that `?U` is [unified] to `Vec<?V>`.
206206
Let's suppose that the type checker decides to revisit the
207207
"as-yet-unproven" trait obligation we saw before, `Vec<?T>:
208208
Borrow<?U>`. `?U` is no longer an unbound inference variable; it now
209-
has a value, &. So, if we "refresh" the query with that value, we get:
209+
has a value, `Vec<?V>`. So, if we "refresh" the query with that value, we get:
210210

211211
Vec<?T>: Borrow<Vec<?V>>
212-
212+
213213
This time, there is only one impl that applies, the reflexive impl:
214214

215215
impl<T> Borrow<T> for T where T: ?Sized

0 commit comments

Comments
 (0)