Please check the build logs for more information.
See Builds for ideas on how to fix a failed build, or Metadata for how to configure docs.rs builds.
If you believe this is docs.rs' fault, open an issue.
In-process test harness for apps built on the standout CLI framework.
[TestHarness] is a fluent builder over the injection seams a test
needs: env vars, cwd, stdin, clipboard, output mode, color/theme facts on
TargetProperties, and tempdir fixtures. run applies every override,
calls into the app in-process, and a Drop impl restores everything on
success or panic. [TestResult] then exposes what the run wrote to each
stream (raw and ANSI-stripped), plus structured facts like style-tag
resolutions that a text search can't get at; [assert_page_snapshot!]
and [matrix] pin a rendered page across output-mode/color/theme cells.
Unset TargetProperties fields take fixed defaults rather than calling
TargetProperties::detect: width: None, ColorMode::Dark,
IconMode::Classic, AmbiguousWidth::Narrow, color capability off, both
streams non-terminal. $COLUMNS/$NERD_FONT/OS appearance cannot
change an in-process run — there is no in-process TTY simulation; use
[TestHarness::run_process] (spawns the real binary) or
[TestHarness::run_pty] (Unix, real pseudo-terminal) for TTY-dependent
behavior.
run mutates process-global state (env vars, cwd) and a child process
inherits the ambient environment/cwd at spawn time, so any test binary
that mixes run with run_process/run_pty needs every such test
annotated #[serial] (re-exported from serial_test) to avoid one
run's overrides leaking into a concurrent spawn.