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.
|
||||
|
||||
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:
|
||||
'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
|
||||
into a tree, where each child extends its parents with some new names.
|
||||
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,
|
||||
there is not just one root universe, but one per item). So consider
|
||||
this function `bar`:
|
||||
|
|
|
|||
|
|
@ -147,7 +147,7 @@ when possible.
|
|||
|
||||
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
|
||||
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`
|
||||
terminator) use a [`ResultsCursor`]. If you need the state at *every* location,
|
||||
a [`ResultsVisitor`] will be more efficient.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# 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
|
||||
`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
|
||||
|
|
|
|||
Loading…
Reference in New Issue