Add a `workspace-deps-lint` helper to the `.github/actions` CI workspace and
run it from a new "Workspace dependency declarations" job in `lint.yml`. It
enforces two rules:
1. every external dependency of a workspace member is declared in the root
`[workspace.dependencies]` and inherited with `workspace = true`;
2. every `[workspace.dependencies]` entry is version-only, i.e.
`default-features = false` and no `features`.
Exceptions are per dependency and justified in a comment, clippy-allow style:
rule 1 needs `# allow(workspace-deps): <justification>` directly above the
dependency, rule 2 needs at least one comment line above the workspace entry
explaining why every member gets that feature (which the existing `flate2`,
`httpmock`, `libc`, `criterion`, `serde_json` and `tempfile` notes already
provide). Path dependencies are crates of this repository and are exempt.
No off-the-shelf tool covers this: cargo-autoinherit, cargo-workspace-deps and
cargo-workspace-inheritance-check only handle rule 1 and have no notion of
documented exceptions, and clippy has no manifest lints. The linter parses
manifests with toml_edit spans so it can tie each finding to a line, and emits
GitHub error annotations on top of the human-readable report.
Also make the tree comply. `blazesym-c`, `cbindgen`, `kernel32-sys`, `winapi`,
`windows` and `windows-sys` move to the workspace level, and members inherit
them while spelling out the features they used to get from default features
(`windows`' `std`, `blazesym-c`'s `dwarf`). Four declarations that genuinely
cannot inherit yet are documented exceptions: `windows` 0.51 in
`datadog-sidecar` and `spawn_worker`, `windows-sys` 0.48 in `libdd-ipc` and the
legacy `winapi` 0.2 in `spawn_worker`. Resolved feature sets are unchanged for
both the linux and windows targets, except that `build_common` no longer pulls
clap in through cbindgen's default features.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
What does this PR do?
Adds a CI check that enforces our dependency declaration policy:
[workspace.dependencies]and inherited withworkspace = true;default-features = falseand nofeatures.Exceptions are allowed per dependency, clippy-allow style: rule 1 needs a
# allow(workspace-deps): <justification>comment above the dependency, rule 2 needs a comment above the workspace entry explaining why every member gets that feature.The check is a small linter in the existing
.github/actionsCI workspace, run from a new job inlint.yml. It reports file and line, and annotates the PR diff. A handful of manifests are brought in line with the rules so the check passes.Motivation
The workspace-dependency migration is essentially done, but nothing stops it from regressing: a new crate can quietly pin its own version, and a workspace entry can quietly turn a feature on for everyone. This makes the policy checkable instead of a review convention, while keeping room for justified exceptions.
No existing tool fits — cargo-autoinherit and friends only cover rule 1 and have no notion of documented exceptions, and clippy has no manifest lints.
Additional Notes
A few pre-existing cases genuinely cannot inherit yet (Windows crates pinned to older major versions); they are documented exceptions rather than migrations, which would need a Windows build to validate. Resolved feature sets are unchanged on both Linux and Windows targets.
How to test the change?
CI: the new "Workspace dependency declarations" job must pass.
Locally:
(cd .github/actions && cargo run -p workspace-deps-lint)To see it fail, drop a dependency with its own version into any member manifest, or enable a feature on a workspace entry, and re-run.
The linter has unit tests for its own rules, run with
(cd .github/actions && cargo test -p workspace-deps-lint)when editing it. Like the other crates under.github/actions, they are not wired into CI.🤖 Generated with Claude Code