diff --git a/src/borrow_check/moves_and_initialization/move_paths.md b/src/borrow_check/moves_and_initialization/move_paths.md index 4d4db411..d733e8ac 100644 --- a/src/borrow_check/moves_and_initialization/move_paths.md +++ b/src/borrow_check/moves_and_initialization/move_paths.md @@ -12,7 +12,7 @@ fn foo() { let b = a.0; // moves a.0 - // a.0 is not initializd, but a.1 still is + // a.0 is not initialized, but a.1 still is let c = a.0; // ERROR let d = a.1; // OK @@ -84,7 +84,7 @@ initialized (which lowers overhead). ## Looking up a move-path -If you have a [`Place`] and you would like to convert it to a [`MovePathIndex`], you +If you have a [`Place`] and you would like to convert it to a [`MovePathIndex`], you can do that using the [`MovePathLookup`] structure found in the [`rev_lookup`] field of [`MoveData`]. There are two different methods: @@ -124,4 +124,3 @@ given move-path (e.g., `a.b`) or any child of that move-path (e.g., [`Place`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/enum.Place.html [`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 - diff --git a/src/borrow_check/region_inference.md b/src/borrow_check/region_inference.md index 46caab56..52659e93 100644 --- a/src/borrow_check/region_inference.md +++ b/src/borrow_check/region_inference.md @@ -236,4 +236,3 @@ tests and universal regions, as discussed above. [`propagate_constraints`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html#method.propagate_constraints [`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 [`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 - diff --git a/src/borrow_check/region_inference/constraint_propagation.md b/src/borrow_check/region_inference/constraint_propagation.md index 7ec46b90..5f3b29c6 100644 --- a/src/borrow_check/region_inference/constraint_propagation.md +++ b/src/borrow_check/region_inference/constraint_propagation.md @@ -137,7 +137,7 @@ by invoking `constraint_sccs.scc(r)`. Working in terms of SCCs allows us to be more efficient: if we have a set of regions `'a...'d` that are part of a single SCC, we don't have -to compute/store their values separarely. We can just store one value +to compute/store their values separately. We can just store one value **for the SCC**, since they must all be equal. 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 constraints. However, in order to complete the process, we must also consider [member constraints][m_c], which are described in [a later section][m_c]. - - diff --git a/src/borrow_check/region_inference/lifetime_parameters.md b/src/borrow_check/region_inference/lifetime_parameters.md index 87e9d53e..0d5219aa 100644 --- a/src/borrow_check/region_inference/lifetime_parameters.md +++ b/src/borrow_check/region_inference/lifetime_parameters.md @@ -52,7 +52,7 @@ based on their index: In fact, the universal regions can be further subdivided based on where they were brought into scope (see the [`RegionClassification`] -type). These subdivions are not important for the topics discussed +type). These subdivisions are not important for the topics discussed here, but become important when we consider [closure constraint propagation](./closure_constraints.html), so we discuss them there. diff --git a/src/borrow_check/region_inference/member_constraints.md b/src/borrow_check/region_inference/member_constraints.md index d69c9551..7e254f0a 100644 --- a/src/borrow_check/region_inference/member_constraints.md +++ b/src/borrow_check/region_inference/member_constraints.md @@ -176,11 +176,11 @@ region being inferred. However, it is somewhat arbitrary. In practice, computing upper bounds is a bit inconvenient, because our data structures are setup for the opposite. What we do is to compute -the **reverse SCC graph** (we do this lazilly and cache the result) -- +the **reverse SCC graph** (we do this lazily and cache the result) -- that is, a graph where `'a: 'b` induces an edge `SCC('b) -> SCC('a)`. Like the normal SCC graph, this is a DAG. We can then do a depth-first search starting from `SCC('0)` in this graph. This will -take us to all the SCCs that must outlive `'0`. +take us to all the SCCs that must outlive `'0`. One wrinkle is that, as we walk the "upper bound" SCCs, their values 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 value for `'a` includes `'a` and the value for `'b` contains `'b`). So we can collect all of the lifetime parameters that are reachable, which is precisely what we are interested in. -