1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
//! Bounds on how much work one validation run may do.
//!
//! # Why a validator needs a budget
//!
//! Validation runs on files a user did not write, in CI, on a schedule. A
//! pathological or hostile file must not turn that into an unbounded run: a
//! 2 GB model with a million dangling references would otherwise produce a
//! million findings and exhaust memory before reporting anything.
//!
//! The budget is a *reporting* limit, not a correctness compromise. When it
//! is hit the report is marked truncated, so "12 errors" never silently means
//! "at least 12 errors".
//!
//! # Why there is no depth limit
//!
//! Every graph walk this crate performs -- supertype chains, SELECT
//! membership, defined-type alias chains -- runs over the *schema's* type
//! graph, never over the file's entity graph. The schema is bundled and
//! finite, so those walks are bounded by its size and guarded against cycles
//! by a visited set (`type_check::select`); a file cannot lengthen them. The
//! per-entity checks are single passes over each record's own slots.
//!
//! A caller-tunable depth would therefore bound nothing a file controls, and
//! a small value would only turn "not yet searched" into "not a member" --
//! the false accusation `type_check::select` documents. The one quantity a
//! file does control is how many findings it provokes, and that is what this
//! budget caps.
/// Limits applied to one validation run.