You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: src/types/closure.md
+12-7Lines changed: 12 additions & 7 deletions
Original file line number
Diff line number
Diff line change
@@ -317,7 +317,7 @@ If a closure captures a field of a composite types such as structs, tuples, and
317
317
* Input:
318
318
* Analyzing the closure C yields a mapping of `Place -> Mode` that are accessed
319
319
* 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.
321
321
* Note: `ByValue` use of a `Copy` type is seen as a `ref` access mode.
322
322
* Closure mode is `ref` or `move`
323
323
* Output:
@@ -383,6 +383,8 @@ If a closure captures a field of a composite types such as structs, tuples, and
383
383
384
384
### box-mut
385
385
386
+
This test shows how a `move` closure can sometimes capture values by mutable reference, if they are reached via a `&mut` reference.
387
+
386
388
```rust
387
389
structFoo { x:i32 }
388
390
@@ -405,10 +407,10 @@ fn box_mut() {
405
407
<!-- ignore: Omit error about unterminated string literal when representing c_prime -->
406
408
```ignore
407
409
Closure mode = move
408
-
C = {
410
+
C_in = {
409
411
(ref mut, (*(*bx)).x)
410
412
}
411
-
C' = C
413
+
C_out = C_in
412
414
```
413
415
414
416
Output is the same: `C' = C`
@@ -439,13 +441,16 @@ fn main() {
439
441
<!-- ignore: Omit error about unterminated string literal when representing c_prime -->
440
442
```ignore
441
443
Closure mode = ref
442
-
C = {
444
+
C_in = {
443
445
(ref mut, packed)
444
446
}
445
-
C' = C
447
+
C_out = C_in
446
448
```
447
449
448
450
### 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.
0 commit comments