Struct Project 

pub struct Project;

The producer namespace: Project::load turns a mount (a SourceTree) into an Environment.

Project is where every ambient/effectful concern lives (filesystem walks, an AssetReader drain, an LSP store, and — later — dependency resolution), quarantined off the pure Environment it produces.

Implementations

impl Project

pub fn load( tree: &dyn SourceTree, entry: &str, overrides: &OptionOverrides, ) -> Result<Environment, LoadError>

Walk tree, read + hash its sources, discover + parse brink.toml over the same tree, apply override precedence, and freeze an Environment.

The tree is treated as rooted at . with root-relative keys (the #1312 SourceTree config-discovery convention): entry is a root-relative key, and any brink.toml is looked up by a direct {ancestor}/brink.toml probe walking up from entry (#1370 — discovery no longer calls list at all, so a mount’s list is not required to surface brink.toml). The mount is responsible for rooting its tree (the CLI drains its project root into an in-memory tree; web / LSP push their own root-relative store).

Sync — the only asynchrony a mount has (e.g. a bevy AssetReader) is quarantined in building the tree, before this runs, matching the InkLoader drain-then-compile pattern.

Dispatches on entry’s extension: a .brink entry’s universe is the whole native source tree (enumerate every .brink key); a .ink entry follows its INCLUDE graph from the entry (a BFS over the tree’s reads).

Repeat compiles are deterministic

Each call resolves AnalysisOptions from a brand-new AnalysisOptions::default() (see resolve_options below) — never one left over from a previous call — so two sequential load calls for unrelated projects never leak dialect/types between them, even though AnalysisOptions::apply_project_config’s “unset means untouched” rule for those two fields would otherwise let a stale value silently survive (see that method’s own “must be fresh” invariant doc). This matters for any caller that calls load repeatedly against different mounts in the same process — notably bevy-brink’s InkLoader, invoked once per .ink asset (re)load — where a leaked dialect would make the n-th load’s outcome depend on what the (n-1)-th load happened to resolve. Pinned by repeat_compiles_do_not_leak_options_across_project_load_calls below.