Skip to content

Commit 9fad89f

Browse files
arora-amanehuss
authored andcommitted
Minor edits from Feedback
1 parent 1035f7d commit 9fad89f

File tree

1 file changed

+12
-7
lines changed

1 file changed

+12
-7
lines changed

src/types/closure.md

Lines changed: 12 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -317,7 +317,7 @@ If a closure captures a field of a composite types such as structs, tuples, and
317317
* Input:
318318
* Analyzing the closure C yields a mapping of `Place -> Mode` that are accessed
319319
* Access mode is `ref`, `ref uniq`, `ref mut`, or `by-value` (ordered least to max)
320-
* For a `Place` that is used in two different acess modes within the same closure, the mode reported from closure analysis is the maximum access mode.
320+
* For a `Place` that is used in two different access modes within the same closure, the mode reported from closure analysis is the maximum access mode.
321321
* Note: `ByValue` use of a `Copy` type is seen as a `ref` access mode.
322322
* Closure mode is `ref` or `move`
323323
* Output:
@@ -383,6 +383,8 @@ If a closure captures a field of a composite types such as structs, tuples, and
383383

384384
### box-mut
385385

386+
This test shows how a `move` closure can sometimes capture values by mutable reference, if they are reached via a `&mut` reference.
387+
386388
```rust
387389
struct Foo { x: i32 }
388390

@@ -405,10 +407,10 @@ fn box_mut() {
405407
<!-- ignore: Omit error about unterminated string literal when representing c_prime -->
406408
```ignore
407409
Closure mode = move
408-
C = {
410+
C_in = {
409411
(ref mut, (*(*bx)).x)
410412
}
411-
C' = C
413+
C_out = C_in
412414
```
413415

414416
Output is the same: `C' = C`
@@ -439,13 +441,16 @@ fn main() {
439441
<!-- ignore: Omit error about unterminated string literal when representing c_prime -->
440442
```ignore
441443
Closure mode = ref
442-
C = {
444+
C_in = {
443445
(ref mut, packed)
444446
}
445-
C' = C
447+
C_out = C_in
446448
```
447449

448450
### Optimization-Edge-Case
451+
452+
This test shows an interesting edge case. Normally, when we see a borrow of something behind a shared reference (`&T`), we truncate to capture the entire reference, because that is more efficient (and we can always use that reference to reach all the data it refers to). However, in the case where we are dereferencing two shared references, we have to be sure to preserve the full path, since otherwise the resulting closure could have a shorter lifetime than is necessary.
453+
449454
```edition2021
450455
struct Int(i32);
451456
struct B<'a>(&'a i32);
@@ -465,10 +470,10 @@ fn foo<'a, 'b>(m: &'a MyStruct<'b>) -> impl FnMut() + 'static {
465470
<!-- ignore: Omit error about unterminated string literal when reprenting c_prime -->
466471
```ignore
467472
Closure mode = ref
468-
C = {
473+
C_in = {
469474
(ref mut, *m.a)
470475
}
471-
C' = C
476+
C_out = C_in
472477
```
473478

474479
# Edition 2018 and before

0 commit comments

Comments
 (0)