Rust 使用可变引用递归更新 app_state

Question

I'm trying to build a parser that can recursively search a file system starting at a root directory (that is passed in by the user) and parse the files / directories within.

I have a Directory struct that holds references to parsed objects. Parsed Objects are held in HashMaps which are part of a State struct.

pub struct Directory<'a> {
    pub pathname: String,
    pub child_dirs: Vec<&'a Directory<'a>>,
    pub child_files: Vec<&'a File>,
    pub child_templates: Vec<&'a Template>,
}

I have an app_state struct that holds all hash maps, like this (some hash maps omitted for brevity):

pub struct State<'a> {
    pub directory_hash: HashMap<OsString, Directory<'a>>,
    pub file_hash: HashMap<PathBuf, File>,
    pub template_hash: HashMap<PathBuf, Template>,
}

The Parser::parse signature looks like this:

pub fn parse<'a>(root: &'a PathBuf, app_state: &'a mut app_state::State<'a>) .

When Parser::parse is called it is passed a &PathBuf for the root directory. Each entry in the root directory will be looked at with two possibilities:

The entry is a directory: ===> 1) Create a new directory object. 2) Save the directory object into the correct directory_hash . 3) Parse the directory by calling the Parser::parse again with this as the root directory, and passing the app_state that we are currently using.

The entry is a file of some type: ===> 1) Parse the file into an object of the correct type. 2) Save the file into the correct hash map on app_state. 3) Save a reference to it into the Vector on the current directory object.

Problem : because this will recursively be called for anything with a depth greater than 1, I can't pass app_state to the Parser::parse method mutably again.

cannot borrow `*app_state` as mutable more than once at a time

mutable borrow starts here in previous iteration of looprustc(E0499)

Where I'm most stuck : This only occurs when I try to store REFERENCES in the vectors that live on the Directory struct. If I were to store actual instances of those objects, this recursive call doesn't error. But I want to store everything in the master app_state object and only reference the rest from elsewhere.

Here's what my Parser::parse code looks like:

pub fn parse<'a>(root: &'a PathBuf, app_state: &'a mut app_state::State<'a>) {
        // Create a new directory object from the root
        let root_dir = Directory::new(root);

        // insert it into the directory hash
        let hash_key = root.clone().into_os_string();
        app_state.directory_hash.insert(hash_key, root_dir);

        // recurse over all entries in the directory
        let readable_dir = fs::read_dir(root);
        let readable_dir = match readable_dir {
            Ok(dir) => dir,
            Err(_e) => return, // handle errors that could occur
        };

        for item in readable_dir {
            let fpath = match item {
                Ok(file_path) => file_path,
                _ => continue, // handle errors that could occur
            };

            // if they are a directory, parse that directory
            if fpath.path().is_dir() {
                Self::parse(&fpath.path(), app_state);
            } else {
            // if not a directory, parse them according to their type
                let file_type = get_file_type(&fpath.path());
                Self::update_state(file_type, &fpath, app_state);
            }

        }
    }

Can someone please help me with this issue? I've tried the suggestions that the compiler gives with adding lifetimes which in simpler situations I understand, but here I am either getting "doesn't live long enough" or "can't borrow mutably more than once" errors.

Can someone illuminate what's happening so I can better understand?

Answer 1

This approach is inherently memory-unsafe: for instance, as the directory_hash grows, at some point its hash table will be rebuilt with different physical locations for the Directory entries, which would leave dangling references in the child_dirs entries. Rust will not allow this, so there is no way to solve this problem by adding/modifying the lifetimes annotations. Instead, a different way of structuring the data is needed.