Fix double-word typos (#1084)
Inspired by #1079. I used this command to find these typos: rg --multiline --pcre2 '\b([a-zA-Z]+) \1\b' src -tmd There were a couple false positives of the form "that that" meaning "that it" or "that this".
This commit is contained in:
parent
b8fb35151f
commit
d6bd146507
|
|
@ -141,7 +141,7 @@ i.e., that `'0` must be *smaller* than. In our example, this would be
|
||||||
examples, the chain may be more indirect.
|
examples, the chain may be more indirect.
|
||||||
|
|
||||||
We can use upper bounds to rule out members in a very similar way to
|
We can use upper bounds to rule out members in a very similar way to
|
||||||
lower lower bounds. If UB is some upper bound, then we know that `UB:
|
lower bounds. If UB is some upper bound, then we know that `UB:
|
||||||
'0` must hold, so we can rule out any choice `'choice` where `UB:
|
'0` must hold, so we can rule out any choice `'choice` where `UB:
|
||||||
'choice` does not hold.
|
'choice` does not hold.
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -75,7 +75,7 @@ index**. The idea of a "universe" is that it is a set of names that
|
||||||
are in scope within some type or at some point. Universes are formed
|
are in scope within some type or at some point. Universes are formed
|
||||||
into a tree, where each child extends its parents with some new names.
|
into a tree, where each child extends its parents with some new names.
|
||||||
So the **root universe** conceptually contains global names, such as
|
So the **root universe** conceptually contains global names, such as
|
||||||
the the lifetime `'static` or the type `i32`. In the compiler, we also
|
the lifetime `'static` or the type `i32`. In the compiler, we also
|
||||||
put generic type parameters into this root universe (in this sense,
|
put generic type parameters into this root universe (in this sense,
|
||||||
there is not just one root universe, but one per item). So consider
|
there is not just one root universe, but one per item). So consider
|
||||||
this function `bar`:
|
this function `bar`:
|
||||||
|
|
|
||||||
|
|
@ -147,7 +147,7 @@ when possible.
|
||||||
|
|
||||||
Calling `iterate_to_fixpoint` on your `Engine` will return a `Results`, which
|
Calling `iterate_to_fixpoint` on your `Engine` will return a `Results`, which
|
||||||
contains the dataflow state at fixpoint upon entry of each block. Once you have
|
contains the dataflow state at fixpoint upon entry of each block. Once you have
|
||||||
a `Results`, you can can inspect the dataflow state at fixpoint at any point in
|
a `Results`, you can inspect the dataflow state at fixpoint at any point in
|
||||||
the CFG. If you only need the state at a few locations (e.g., each `Drop`
|
the CFG. If you only need the state at a few locations (e.g., each `Drop`
|
||||||
terminator) use a [`ResultsCursor`]. If you need the state at *every* location,
|
terminator) use a [`ResultsCursor`]. If you need the state at *every* location,
|
||||||
a [`ResultsVisitor`] will be more efficient.
|
a [`ResultsVisitor`] will be more efficient.
|
||||||
|
|
|
||||||
|
|
@ -1,6 +1,6 @@
|
||||||
# Parameter Environment
|
# Parameter Environment
|
||||||
|
|
||||||
When working with associated and/or or generic items (types, constants,
|
When working with associated and/or generic items (types, constants,
|
||||||
functions/methods) it is often relevant to have more information about the
|
functions/methods) it is often relevant to have more information about the
|
||||||
`Self` or generic parameters. Trait bounds and similar information is encoded in
|
`Self` or generic parameters. Trait bounds and similar information is encoded in
|
||||||
the [`ParamEnv`][pe]. Often this is not enough information to obtain things like the
|
the [`ParamEnv`][pe]. Often this is not enough information to obtain things like the
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue