|
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