Rust and Tooling
The Rust workspace vocabulary and the checks that gate a change.
MSRV
Also known as: minimum supported Rust version
The oldest toolchain release a crate compiles with, declared as
rust-version in its manifest.
Distinct from the toolchain a project builds with. The first is a compatibility promise to consumers; the second is a reproducibility control for the project.
Why it matters here
fragcap declares 1.82 while pinning its build toolchain at 1.96.0. A declared minimum that is never exercised is an unverified claim, so a dedicated check builds at the minimum. That check is currently vacuous, since the workspace has no external dependencies, and it says so in its own output.
See also: xtask
Test tier
One of the four levels specification section 25.2 defines, distinguished by what each needs in order to run.
| Tier | Needs | In continuous integration |
|---|---|---|
| 0, unit | nothing | yes |
| 1, pipeline | nothing | yes |
| 2, platform | privilege and a capture driver | yes, on a Windows runner |
| 3, live | privilege, a driver, and a game | no, manual |
Why it matters here
Tier 1 is the one the architecture was shaped to make possible. Because a replay source and a scripted attributor substitute for the two platform-dependent seams, the whole pipeline is testable on any machine with no privilege. That is the return on keeping capture and attribution apart.
See also: Fixture corpus, Replay source
xtask
A Cargo convention in which repository-wide tasks are implemented as a workspace member invoked through a cargo alias, requiring nothing installed beyond the language toolchain.
Why it matters here
fragcap's conventions and dependency-direction checks live here rather than in shell scripts, because a check written in the project's own language can be unit tested against known-bad input. A linter whose matcher never fires is indistinguishable from a clean repository.