pub fn load_package_sources_into(
package_dir: &Path,
root: SourceRoot,
package: Option<&PackageName>,
overlay: &Overlay,
sources: &mut SourceFiles,
) -> Result<Vec<SourceFileId>, CompilationError>Expand description
Walk one source root of the package rooted at package_dir for .zel files, add
each one to files, and return the id each was given.
A package has two source roots and they are walked separately, because a module’s
name is its path under its own root: src/Model.zel and tests/Model.zel are
both Model (Source
roots). Each file carries the root
it came from, so a diagnostic can tell the two apart.
A package must have a src/, and a walk of one that is not there is the error
WalkDir reports. A tests/ that is not there is a package that holds no tests,
which is not an error and loads as no modules at all.
A build holds one file database for every package in it, because a
SourceFileId travels inside an Interface and outlives the
package it came from (ERR-5), so the ids of two packages have to be drawn from one
sequence. This is the entry point that appends into that shared database;
load_package_sources is the same walk over a database of its own, which is what
a caller compiling exactly one source root wants.
package names the package package_dir holds, and every caller sharing a database
across packages has to pass it: a path relative to a package’s own src/ is not
unique in a build — two packages may each hold a Size.zel — so without it a
diagnostic cannot say which package it is about.
overlay holds the text of buffers that are open in an editor: a file it holds is
read from there instead of from disk, and a .zel file under the root that only the
overlay holds is loaded after the walked ones, in path order. Overlay has the
rules.
The ids come back rather than the files themselves: files is borrowed mutably for
the walk, and the caller needs it borrowed immutably afterwards to read the sources
back out.