Minor grammar and syntax fixes

Minor grammar and syntax fixes found while reading.
This commit is contained in:
Dan Robertson 2018-03-25 13:50:58 +00:00
parent 6723308d21
commit 52520205a3
3 changed files with 10 additions and 6 deletions

View File

@ -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

View File

@ -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`.

View File

@ -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