@@ -20,7 +20,7 @@ will run off and start supplying you with every possible answer it can
20
20
find. So given something like this:
21
21
22
22
?- Vec<i32>: AsRef<?U>
23
-
23
+
24
24
The solver might answer:
25
25
26
26
Vec<i32>: AsRef<[i32]>
@@ -71,27 +71,27 @@ Another interesting thing is that queries might still have variables
71
71
in them. For example:
72
72
73
73
?- Rc<?T>: Clone
74
-
74
+
75
75
might produce the answer:
76
76
77
77
Rc<?T>: Clone
78
78
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 " >
81
83
82
84
## A trait query in rustc
83
85
84
86
The trait queries in rustc work somewhat differently. Instead of
85
87
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
87
89
value for a type variable, that means that this is the ** only possible
88
90
instantiation** that you could use, given the current set of impls and
89
91
where-clauses, that would be provable. (Internally within the solver,
90
92
though, they can potentially enumerate all possible answers. See
91
93
[ the description of the SLG solver] ( ./traits-slg.html ) for details.)
92
94
93
- <a name =query-response >
94
-
95
95
The response to a trait query in rustc is typically a
96
96
` Result<QueryResult<T>, NoSolution> ` (where the ` T ` will vary a bit
97
97
depending on the query itself). The ` Err(NoSolution) ` case indicates
@@ -191,7 +191,7 @@ fn main() {
191
191
let mut t : Vec <_ > = vec! []; // Type: Vec<?T>
192
192
let mut u : Option <_ > = None ; // Type: Option<?U>
193
193
foo (t , u ); // `Vec<?T>: Borrow<?U>` => ambiguous
194
-
194
+
195
195
// New stuff:
196
196
u = Some (vec! []); // ?U = Vec<?V>
197
197
}
@@ -206,10 +206,10 @@ vector. This in turn implies that `?U` is [unified] to `Vec<?V>`.
206
206
Let's suppose that the type checker decides to revisit the
207
207
"as-yet-unproven" trait obligation we saw before, `Vec<?T>:
208
208
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:
210
210
211
211
Vec<?T>: Borrow<Vec<?V>>
212
-
212
+
213
213
This time, there is only one impl that applies, the reflexive impl:
214
214
215
215
impl<T> Borrow<T> for T where T: ?Sized
0 commit comments