pub struct FragmentCorpus { /* private fields */ }Expand description
Every fragment file’s text, scanned at most once however many times the packs around it are loaded (ADR-0018).
One proef test loads packs up to four times — the suite, then [run] setup
and [run] teardown, each validated and then run — against different feature
paths but always the same corpus. Rescanning per load measured ~75% of a
run’s total work on a 200-file corpus, and it grows with the corpus, which is
the direction adoption goes.
The memo lives here rather than in the caller because the scan must stay
lazy: load_collecting runs it only when some pack actually has a
ref:, which is what makes CONFIG.md’s “pointing at a corpus you did not
write costs nothing” true of the scan. A caller that scanned eagerly in
order to share the result would buy speed by breaking that promise. Nothing
here reads a file — the texts arrive already read, so core stays sans-IO.
Implementations§
Source§impl FragmentCorpus
impl FragmentCorpus
Sourcepub fn new(sources: Vec<PackSource>, kinds: &[StepKindSpec]) -> Self
pub fn new(sources: Vec<PackSource>, kinds: &[StepKindSpec]) -> Self
A corpus over already-read file texts.
Sourcepub fn with_read_errors(self, errors: Vec<Diag>) -> Self
pub fn with_read_errors(self, errors: Vec<Diag>) -> Self
Record files the caller could not read. They are reported like any other
per-file corpus problem — never sinking their siblings, and never at all
unless something ref:s the corpus.
Sourcepub fn unreadable_file(name: &str, cause: &str) -> Diag
pub fn unreadable_file(name: &str, cause: &str) -> Diag
The diagnostic for a corpus file that could not be read at all.
Here rather than at each caller because there are two — the CLI walks the fragment root, the editor reads through its overlay provider — and they had drifted: the CLI’s carried the “the rest of the corpus still loads” help that is the whole point of per-file resilience, and the editor’s did not, so the same unreadable file explained itself in the terminal and went unexplained in the pane beside the code. The reading differs and always will; what it means when reading fails does not.
Sourcepub fn empty() -> Self
pub fn empty() -> Self
The empty corpus — no [run] fragments configured, so no ref: can
resolve and nothing is ever scanned.
Sourcepub fn fragments(&self) -> &BTreeMap<String, Fragment>
pub fn fragments(&self) -> &BTreeMap<String, Fragment>
Every annotated fragment in the corpus, keyed by name. Scans on first use, like every other reader.
Public because the scan is otherwise gated: load parses the corpus
only when some pack actually names a fragment, so PackSet::fragments
is empty for a suite that references none — which is exactly the suite a
listing has the most to say about.
Sourcepub fn unannotated(&self) -> &BTreeMap<String, Vec<usize>>
pub fn unannotated(&self) -> &BTreeMap<String, Vec<usize>>
Per file, the 1-based lines of entries carrying no # @proef
annotation — the one class of corpus content nothing else can report,
since an unannotated entry has no name to be listed by.
Sourcepub fn diagnostics(&self) -> &[Diag]
pub fn diagnostics(&self) -> &[Diag]
Whatever was wrong with the corpus: unreadable files first, then scan failures. Already shaped as diagnostics.