Skip to content

Commit 1774649

Browse files
JohnTitormark-i-m
authored andcommitted
Minor fix in borrow_check
Fixes as follows: - fixes spelling - removes unnecessary white spaces and blank lines
1 parent fc18a79 commit 1774649

File tree

5 files changed

+6
-11
lines changed

5 files changed

+6
-11
lines changed

src/borrow_check/moves_and_initialization/move_paths.md

Lines changed: 2 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -12,7 +12,7 @@ fn foo() {
1212
1313
let b = a.0; // moves a.0
1414
15-
// a.0 is not initializd, but a.1 still is
15+
// a.0 is not initialized, but a.1 still is
1616
1717
let c = a.0; // ERROR
1818
let d = a.1; // OK
@@ -84,7 +84,7 @@ initialized (which lowers overhead).
8484

8585
## Looking up a move-path
8686

87-
If you have a [`Place`] and you would like to convert it to a [`MovePathIndex`], you
87+
If you have a [`Place`] and you would like to convert it to a [`MovePathIndex`], you
8888
can do that using the [`MovePathLookup`] structure found in the [`rev_lookup`] field
8989
of [`MoveData`]. There are two different methods:
9090

@@ -124,4 +124,3 @@ given move-path (e.g., `a.b`) or any child of that move-path (e.g.,
124124

125125
[`Place`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/enum.Place.html
126126
[`has_any_child_of`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/at_location/struct.FlowAtLocation.html#method.has_any_child_of
127-

src/borrow_check/region_inference.md

Lines changed: 0 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -236,4 +236,3 @@ tests and universal regions, as discussed above.
236236
[`propagate_constraints`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html#method.propagate_constraints
237237
[`check_type_tests`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html#method.check_type_tests
238238
[`check_universal_regions`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html#method.check_universal_regions
239-

src/borrow_check/region_inference/constraint_propagation.md

Lines changed: 1 addition & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -137,7 +137,7 @@ by invoking `constraint_sccs.scc(r)`.
137137

138138
Working in terms of SCCs allows us to be more efficient: if we have a
139139
set of regions `'a...'d` that are part of a single SCC, we don't have
140-
to compute/store their values separarely. We can just store one value
140+
to compute/store their values separately. We can just store one value
141141
**for the SCC**, since they must all be equal.
142142

143143
If you look over the region inference code, you will see that a number
@@ -220,5 +220,3 @@ taking into account all of the liveness and outlives
220220
constraints. However, in order to complete the process, we must also
221221
consider [member constraints][m_c], which are described in [a later
222222
section][m_c].
223-
224-

src/borrow_check/region_inference/lifetime_parameters.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -52,7 +52,7 @@ based on their index:
5252

5353
In fact, the universal regions can be further subdivided based on
5454
where they were brought into scope (see the [`RegionClassification`]
55-
type). These subdivions are not important for the topics discussed
55+
type). These subdivisions are not important for the topics discussed
5656
here, but become important when we consider [closure constraint
5757
propagation](./closure_constraints.html), so we discuss them there.
5858

src/borrow_check/region_inference/member_constraints.md

Lines changed: 2 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -176,11 +176,11 @@ region being inferred. However, it is somewhat arbitrary.
176176

177177
In practice, computing upper bounds is a bit inconvenient, because our
178178
data structures are setup for the opposite. What we do is to compute
179-
the **reverse SCC graph** (we do this lazilly and cache the result) --
179+
the **reverse SCC graph** (we do this lazily and cache the result) --
180180
that is, a graph where `'a: 'b` induces an edge `SCC('b) ->
181181
SCC('a)`. Like the normal SCC graph, this is a DAG. We can then do a
182182
depth-first search starting from `SCC('0)` in this graph. This will
183-
take us to all the SCCs that must outlive `'0`.
183+
take us to all the SCCs that must outlive `'0`.
184184

185185
One wrinkle is that, as we walk the "upper bound" SCCs, their values
186186
will not yet have been fully computed. However, we **have** already
@@ -190,4 +190,3 @@ parameters, their value will contain themselves (i.e., the initial
190190
value for `'a` includes `'a` and the value for `'b` contains `'b`). So
191191
we can collect all of the lifetime parameters that are reachable,
192192
which is precisely what we are interested in.
193-

0 commit comments

Comments
 (0)