|
1 |
| -//! The move-analysis portion of borrowck needs to work in an abstract |
2 |
| -//! domain of lifted `Place`s. Most of the `Place` variants fall into a |
3 |
| -//! one-to-one mapping between the concrete and abstract (e.g., a |
4 |
| -//! field-deref on a local variable, `x.field`, has the same meaning |
5 |
| -//! in both domains). Indexed projections are the exception: `a[x]` |
6 |
| -//! needs to be treated as mapping to the same move path as `a[y]` as |
7 |
| -//! well as `a[13]`, etc. So we map these `x`/`y` values to `()`. |
| 1 | +//! The move-analysis portion of borrowck needs to work in an abstract domain of lifted `Place`s. |
| 2 | +//! Most of the `Place` variants fall into a one-to-one mapping between the concrete and abstract |
| 3 | +//! (e.g., a field projection on a local variable, `x.field`, has the same meaning in both |
| 4 | +//! domains). In other words, all field projections for the same field on the same local do not |
| 5 | +//! have meaningfully different types if ever. Indexed projections are the exception: `a[x]` needs |
| 6 | +//! to be treated as mapping to the same move path as `a[y]` as well as `a[13]`, etc. So we map |
| 7 | +//! these `x`/`y` values to `()`. |
8 | 8 | //!
|
9 |
| -//! (In theory, the analysis could be extended to work with sets of |
10 |
| -//! paths, so that `a[0]` and `a[13]` could be kept distinct, while |
11 |
| -//! `a[x]` would still overlap them both. But that is not this |
12 |
| -//! representation does today.) |
| 9 | +//! (In theory, the analysis could be extended to work with sets of paths, so that `a[0]` and |
| 10 | +//! `a[13]` could be kept distinct, while `a[x]` would still overlap them both. But that is not |
| 11 | +//! what this representation does today.) |
13 | 12 |
|
14 | 13 | use std::fmt;
|
15 | 14 | use std::ops::{Index, IndexMut};
|
|
0 commit comments