Virtual File System

VFS records all file changes pushed to it via set_file_contents. As such it only ever stores changes, not the actual content of a file at any given moment. All file changes are logged, and can be retrieved via take_changes method. The pack of changes is then pushed to salsa and triggers incremental recomputation.

Files in VFS are identified with [FileId]s -- interned paths. The notion of the path, [VfsPath] is somewhat abstract: at the moment, it is represented as an [std::path::PathBuf] internally, but this is an implementation detail.

VFS doesn't do IO or file watching itself. For that, see the [loader] module. [loader::Handle] is an object-safe trait which abstracts both file loading and file watching. Handle is dynamically configured with a set of directory entries which should be scanned and watched. Handle then asynchronously pushes file changes. Directory entries are configured in free-form via list of globs, it's up to the Handle to interpret the globs in any specific way.

VFS stores a flat list of files. [file_set::FileSet] can partition this list of files into disjoint sets of files. Traversal-like operations (including getting the neighbor file by the relative path) are handled by the FileSet. FileSets are also pushed to salsa and cause it to re-check mod foo; declarations when files are created or deleted.

FileSet and [loader::Entry] play similar, but different roles. Both specify the "set of paths/files", one is geared towards file watching, the other towards salsa changes. In particular, single FileSet may correspond to several [loader::Entry]. For example, a crate from crates.io which uses code generation would have two Entries -- for sources in ~/.cargo, and for generated code in ./target/debug/build. It will have a single FileSet which unions the two sources.