Minor grammar and syntax fixes
Minor grammar and syntax fixes found while reading.
This commit is contained in:
parent
6723308d21
commit
52520205a3
|
|
@ -54,7 +54,7 @@ use is done by the method `pick_candidate_cache` in `select.rs`. At
|
||||||
the moment, we use a very simple, conservative rule: if there are any
|
the moment, we use a very simple, conservative rule: if there are any
|
||||||
where-clauses in scope, then we use the local cache. We used to try
|
where-clauses in scope, then we use the local cache. We used to try
|
||||||
and draw finer-grained distinctions, but that led to a serious of
|
and draw finer-grained distinctions, but that led to a serious of
|
||||||
annoying and weird bugs like #22019 and #18290. This simple rule seems
|
annoying and weird bugs like [#22019] and [#18290]. This simple rule seems
|
||||||
to be pretty clearly safe and also still retains a very high hit rate
|
to be pretty clearly safe and also still retains a very high hit rate
|
||||||
(~95% when compiling rustc).
|
(~95% when compiling rustc).
|
||||||
|
|
||||||
|
|
@ -63,3 +63,5 @@ general, is this section still accurate at all?
|
||||||
|
|
||||||
[`ParamEnv`]: ./param_env.html
|
[`ParamEnv`]: ./param_env.html
|
||||||
[`tcx`]: ./ty.html
|
[`tcx`]: ./ty.html
|
||||||
|
[#18290]: https://github.com/rust-lang/rust/issues/18290
|
||||||
|
[#22019]: https://github.com/rust-lang/rust/issues/22019
|
||||||
|
|
|
||||||
|
|
@ -20,6 +20,8 @@ that syntax is expanded during
|
||||||
["type collection"](./type-checking.html) into the explicit form,
|
["type collection"](./type-checking.html) into the explicit form,
|
||||||
though that is something we may want to change in the future.)
|
though that is something we may want to change in the future.)
|
||||||
|
|
||||||
|
[intoiter-item]: https://doc.rust-lang.org/nightly/core/iter/trait.IntoIterator.html#associatedtype.Item
|
||||||
|
|
||||||
<a name=normalize>
|
<a name=normalize>
|
||||||
|
|
||||||
In some cases, associated type projections can be **normalized** --
|
In some cases, associated type projections can be **normalized** --
|
||||||
|
|
@ -51,8 +53,8 @@ we saw above would be lowered to a program clause like so:
|
||||||
|
|
||||||
forall<T> {
|
forall<T> {
|
||||||
Normalize(<Option<T> as IntoIterator>::Item -> T)
|
Normalize(<Option<T> as IntoIterator>::Item -> T)
|
||||||
}
|
}
|
||||||
|
|
||||||
(An aside: since we do not permit quantification over traits, this is
|
(An aside: since we do not permit quantification over traits, this is
|
||||||
really more like a family of predicates, one for each associated
|
really more like a family of predicates, one for each associated
|
||||||
type.)
|
type.)
|
||||||
|
|
@ -98,7 +100,7 @@ We now introduce the `ProjectionEq` predicate to bring those two cases
|
||||||
together. The `ProjectionEq` predicate looks like so:
|
together. The `ProjectionEq` predicate looks like so:
|
||||||
|
|
||||||
ProjectionEq(<T as IntoIterator>::Item = U)
|
ProjectionEq(<T as IntoIterator>::Item = U)
|
||||||
|
|
||||||
and we will see that it can be proven *either* via normalization or
|
and we will see that it can be proven *either* via normalization or
|
||||||
skolemization. As part of lowering an associated type declaration from
|
skolemization. As part of lowering an associated type declaration from
|
||||||
some trait, we create two program clauses for `ProjectionEq`:
|
some trait, we create two program clauses for `ProjectionEq`:
|
||||||
|
|
@ -123,7 +125,7 @@ with unification. As described in the
|
||||||
basically a procedure with a signature like this:
|
basically a procedure with a signature like this:
|
||||||
|
|
||||||
Unify(A, B) = Result<(Subgoals, RegionConstraints), NoSolution>
|
Unify(A, B) = Result<(Subgoals, RegionConstraints), NoSolution>
|
||||||
|
|
||||||
In other words, we try to unify two things A and B. That procedure
|
In other words, we try to unify two things A and B. That procedure
|
||||||
might just fail, in which case we get back `Err(NoSolution)`. This
|
might just fail, in which case we get back `Err(NoSolution)`. This
|
||||||
would happen, for example, if we tried to unify `u32` and `i32`.
|
would happen, for example, if we tried to unify `u32` and `i32`.
|
||||||
|
|
|
||||||
|
|
@ -84,7 +84,7 @@ below in a separate section.
|
||||||
|
|
||||||
The most basic operations you can perform in the type inferencer is
|
The most basic operations you can perform in the type inferencer is
|
||||||
**equality**, which forces two types `T` and `U` to be the same. The
|
**equality**, which forces two types `T` and `U` to be the same. The
|
||||||
recommended way to add an equality constraint is using the `at`
|
recommended way to add an equality constraint is to use the `at`
|
||||||
method, roughly like so:
|
method, roughly like so:
|
||||||
|
|
||||||
```rust
|
```rust
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue