Move Path Construction, Lookup, and Cross-references

example, to convert a [`MovePathIndex`] `mpi` into a MIR [`Place`], you might access the [`MovePath::place`] field like so: ```rust,ignore move_data.move_paths[mpi].place ``` ## Building move paths One of the first things we do in the MIR borrow check is to construct the set of move paths. This is done as part of the [`MoveData::gather_moves`] function. This function uses a MIR visitor called [`MoveDataBuilder`] to walk the MIR and look at how each [`Place`] within is accessed. For each such [`Place`], it constructs a corresponding [`MovePathIndex`]. It also records when/where that particular move path is moved/initialized, but we'll get to that in a later section. ### Illegal move paths We don't actually create a move-path for **every** [`Place`] that gets used. In particular, if it is illegal to move from a [`Place`], then there is no need for a [`MovePathIndex`]. Some examples: - You cannot move from a static variable, so we do not create a [`MovePathIndex`] for static variables. - You cannot move an individual element of an array, so if we have e.g. `foo: [String; 3]`, there would be no move-path for `foo[1]`. - You cannot move from inside of a borrowed reference, so if we have e.g. `foo: &String`, there would be no move-path for `*foo`. These rules are enforced by the [`move_path_for`] function, which converts a [`Place`] into a [`MovePathIndex`] -- in error cases like those just discussed, the function returns an `Err`. This in turn means we don't have to bother tracking whether those places are initialized (which lowers overhead). ## Looking up a move-path If you have a [`Place`] and you would like to convert it to a [`MovePathIndex`], you can do that using the [`MovePathLookup`] structure found in the [`rev_lookup`] field of [`MoveData`]. There are two different methods: - [`find_local`], which takes a [`mir::Local`] representing a local variable. This is the easier method, because we **always** create a [`MovePathIndex`] for every local variable. - [`find`], which takes an arbitrary [`Place`]. This method is a bit more annoying to use, precisely because we don't have a [`MovePathIndex`] for **every** [`Place`] (as we just discussed in the "illegal move paths" section). Therefore, [`find`] returns a [`LookupResult`] indicating the closest path it was able to find that exists (e.g., for `foo[1]`, it might return just the path for `foo`). ## Cross-references As we noted above, move-paths are stored in a big vector and referenced via their [`MovePathIndex`]. However, within this vector, they are also structured into a tree. So for example if you have the [`MovePathIndex`] for `a.b.c`, you can go to its parent move-path `a.b`. You can also iterate over all children paths: so, from `a.b`, you might iterate to find the path `a.b.c` (here you are iterating just over the paths that are **actually referenced** in the source, not all **possible** paths that could have been referenced). These references are used for example in the [`find_in_move_path_or_its_descendants`] function, which determines whether a move-path (e.g., `a.b`) or any child of that move-path (e.g.,`a.b.c`) matches a given predicate.

Move paths are not created for every `Place`, only those that are legal to move from (excluding static variables, array elements, and dereferenced borrowed references). The `move_path_for` function handles this, returning an error for illegal move paths. To convert a `Place` to a `MovePathIndex`, use `MovePathLookup` via `find_local` (for local variables) or `find` (for arbitrary `Place`s), which returns a `LookupResult`. Move paths are stored in a vector, structured as a tree, allowing navigation to parent and child paths, useful in functions like `find_in_move_path_or_its_descendants`.