Skip to content

Commit ac26129

Browse files
arora-amanehuss
authored andcommitted
Minor edits from Feedback
1 parent 3b222a2 commit ac26129

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
@@ -331,7 +331,7 @@ If a closure captures a field of a composite types such as structs, tuples, and
331331
* Input:
332332
* Analyzing the closure C yields a mapping of `Place -> Mode` that are accessed
333333
* Access mode is `ref`, `ref uniq`, `ref mut`, or `by-value` (ordered least to max)
334-
* 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.
334+
* 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.
335335
* Note: `ByValue` use of a `Copy` type is seen as a `ref` access mode.
336336
* Closure mode is `ref` or `move`
337337
* Output:
@@ -397,6 +397,8 @@ If a closure captures a field of a composite types such as structs, tuples, and
397397

398398
### box-mut
399399

400+
This test shows how a `move` closure can sometimes capture values by mutable reference, if they are reached via a `&mut` reference.
401+
400402
```rust
401403
struct Foo { x: i32 }
402404

@@ -419,10 +421,10 @@ fn box_mut() {
419421
<!-- ignore: Omit error about unterminated string literal when representing c_prime -->
420422
```ignore
421423
Closure mode = move
422-
C = {
424+
C_in = {
423425
(ref mut, (*(*bx)).x)
424426
}
425-
C' = C
427+
C_out = C_in
426428
```
427429

428430
Output is the same: `C' = C`
@@ -453,13 +455,16 @@ fn main() {
453455
<!-- ignore: Omit error about unterminated string literal when representing c_prime -->
454456
```ignore
455457
Closure mode = ref
456-
C = {
458+
C_in = {
457459
(ref mut, packed)
458460
}
459-
C' = C
461+
C_out = C_in
460462
```
461463

462464
### Optimization-Edge-Case
465+
466+
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.
467+
463468
```edition2021
464469
struct Int(i32);
465470
struct B<'a>(&'a i32);
@@ -479,10 +484,10 @@ fn foo<'a, 'b>(m: &'a MyStruct<'b>) -> impl FnMut() + 'static {
479484
<!-- ignore: Omit error about unterminated string literal when reprenting c_prime -->
480485
```ignore
481486
Closure mode = ref
482-
C = {
487+
C_in = {
483488
(ref mut, *m.a)
484489
}
485-
C' = C
490+
C_out = C_in
486491
```
487492

488493
# Edition 2018 and before

0 commit comments

Comments
 (0)