Summary
NoStdFsConfig is declared #[serde(default, deny_unknown_fields)], so a dylint.toml containing a key the running suite does not know about fails to deserialize as a whole. The lint then falls back to Default, silently dropping every exclusion — including keys that suite version does support — with no diagnostic.
Why this matters under rolling suites
The dylint libraries roll while the installer is versioned, so config/suite skew is an expected state rather than an exotic one. A consumer repository whose dylint.toml uses a newer key does not get "that one key ignored"; it gets its entire exclusion policy switched off.
Concretely, with a suite predating dbc930a ("Add module-path suppression to no_std_fs_operations"), this config:
[no_std_fs_operations]
excluded_paths = [ "netsuke::cli::discovery::paths" ] # unknown to the old suite
excluded_crates = [ "build_script_build", "test_support" ]
loses excluded_crates too. In leynos/netsuke that produced 9 no_std_fs_operations errors across build.rs, build_l10n_audit.rs and others that had been excluded for a long time, making make lint fail repo-wide.
The failure is silent and misattributing: nothing reports that the config was discarded, so the obvious hypotheses are all wrong ones — a bad code change, a mis-scoped exclusion, a corrupted dylint.toml. The tooling is the last place one looks.
Suggested behaviour
Any of these would remove the sharp edge, roughly in order of preference:
- Warn and continue on unknown keys — apply the keys this suite understands, and emit a diagnostic naming the ignored key and the suite revision. Forward-compatible by construction.
- Fail loudly — abort with a message naming the unrecognized key, rather than proceeding with an empty policy. Noisy but never silently unsound.
- Keep
deny_unknown_fields, but report the deserialization error instead of falling back to Default silently.
Option 1 seems the best fit for rolling libraries: a consumer adopting a new key should not have their existing exclusions collapse when a machine happens to be running an older suite.
Related
Environment
cargo-dylint 6.0.1, toolchain nightly-2026-05-28- Reproduced against
leynos/netsuke at dylint.toml using excluded_paths + excluded_crates
Summary
NoStdFsConfigis declared#[serde(default, deny_unknown_fields)], so adylint.tomlcontaining a key the running suite does not know about fails to deserialize as a whole. The lint then falls back toDefault, silently dropping every exclusion — including keys that suite version does support — with no diagnostic.Why this matters under rolling suites
The dylint libraries roll while the installer is versioned, so config/suite skew is an expected state rather than an exotic one. A consumer repository whose
dylint.tomluses a newer key does not get "that one key ignored"; it gets its entire exclusion policy switched off.Concretely, with a suite predating
dbc930a("Add module-path suppression tono_std_fs_operations"), this config:loses
excluded_cratestoo. Inleynos/netsukethat produced 9no_std_fs_operationserrors acrossbuild.rs,build_l10n_audit.rsand others that had been excluded for a long time, makingmake lintfail repo-wide.The failure is silent and misattributing: nothing reports that the config was discarded, so the obvious hypotheses are all wrong ones — a bad code change, a mis-scoped exclusion, a corrupted
dylint.toml. The tooling is the last place one looks.Suggested behaviour
Any of these would remove the sharp edge, roughly in order of preference:
deny_unknown_fields, but report the deserialization error instead of falling back toDefaultsilently.Option 1 seems the best fit for rolling libraries: a consumer adopting a new key should not have their existing exclusions collapse when a machine happens to be running an older suite.
Related
Environment
cargo-dylint6.0.1, toolchainnightly-2026-05-28leynos/netsukeatdylint.tomlusingexcluded_paths+excluded_crates