Configuration diagnostics now name the file each setting came from. For example, cargo nextest show-config version shows which file specified the nextest-version requirement, and cargo nextest show-config test-groups shows which file each override was defined in.
For now, this is most useful when tool-specific config files are in play, but upcoming work to support local configuration files also benefits from this. (#3580, #3584)
Config file paths in errors and warnings are now displayed relative to the directory nextest is invoked from, following typical CLI conventions. Previously, parse errors showed absolute paths and warnings showed paths relative to the workspace root. In stylized output, config file paths are now colored as well. (#3568, #3570, #3577)
Fixed
Per-test overrides and setup and wrapper scripts defined in a profile's inheritance chain are now applied. Previously, only the selected profile's own overrides and those in profile.default were consulted, so overrides in intermediate profiles were silently skipped. As part of this change, a profile that does not set default-filter now inherits it from the nearest ancestor that does, rather than always from profile.default. (#3585)
A default-filter set by a tool config file is now respected when the repository config does not set one. Previously, the tool's filter was ignored and all() was used. (#3592)
Profile inheritance cycles that span multiple config files, such as a tool config file redefining a profile that the repository config inherits from, are now detected and reported as errors. Previously, cycles were only detected within a single file. (#3588)
Passing --tool-config-file more than once for the same tool name now produces an error. Previously, nextest panicked internally. (#3589)
The hint shown when a command requires an experimental feature that isn't enabled now points at the correct config file path when nextest is run from a subdirectory of the workspace, from outside the workspace, or with an explicit --config-file. (#3565)
On Unix platforms where the Rust standard library cannot create pipes with FD_CLOEXEC set atomically (most notably Apple platforms), a test could inherit a sibling test's capture pipe if the two were spawned concurrently. The sibling was then reported as having leaked handles after it exited. Nextest now creates capture pipes itself and coordinates pipe creation with process spawning, so that spawns no longer inherit stray pipes. (#3553)
An upcoming design document will go over how nextest spawns processes in detail, including more information about this workaround.
Thanks gaborbernat for your first contribution!
