Adopt the Whitaker Dylint suite in the lint gate and CI - #30
Conversation
Prepare the codebase for the Whitaker Dylint suite by resolving every finding it reports: - Build the Tokio runtime explicitly in `main` so runtime construction errors propagate as `Result` instead of panicking inside the `#[tokio::main]` expansion (`no_expect_outside_tests`). - Create the store root with `cap_std::fs::Dir::create_ambient_dir_all` so the single ambient filesystem operation is explicit, and write test fixtures through a capability-scoped `Dir` handle rooted at the temporary directory (`no_std_fs_operations`). - Return `anyhow::Result` from the `user` test helpers and consume them with `?`, replacing panicking `unwrap_or_else` closures; use `anyhow::ensure!` in the now-fallible tests because the crate denies `clippy::panic_in_result_fn` (`no_unwrap_or_else_panic`). - Add `//!` inner doc comments to every unit test module (`module_must_have_inner_docs`). Adds a `cap-std` dependency for the capability-based filesystem handles.
Run the Whitaker Dylint suite (v0.2.5) alongside Clippy so the capability-based filesystem, panic-hygiene, and module-documentation lints gate every change: - Makefile: add a `WHITAKER` tool variable and run `whitaker --all -- --all-targets --all-features` with warnings denied after Clippy in the `lint` target. - CI: cache and install `whitaker-installer` (via `cargo binstall` when available, falling back to `cargo install --locked`) before the lint step, pinned to v0.2.5. Part of the estate-wide Whitaker rollout; mirrors the adoption in leynos/netsuke#410.
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 59 minutes Your organization has reached its usage spending cap. Adjust your spending cap in the billing tab. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (13)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![codescene-access[bot]](https://avatars.githubusercontent.com/in/3755875?s=60&v=4){kind=small}
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: afaba07b7e
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Replace inline `${{ env.WHITAKER_INSTALLER_VERSION }}` interpolation in the
run block with the plain shell variable `"${WHITAKER_INSTALLER_VERSION}"`;
the job-level `env:` already exports it, and zizmor flags run-block template
interpolation as a template-injection hazard. Add `--locked` to the
cargo-binstall invocation so that binstall's compile fallback resolves
dependencies from the published lockfile, keeping fallback builds
reproducible.
Collapse the five near-identical rejection tests in src/user.rs (rejects_mismatched_username, rejects_invalid_username_value, rejects_missing_username_field, rejects_non_string_value and rejects_invalid_toml) into a single rstest-parameterized case that takes the profile body and an error-variant predicate per case. This addresses the CodeScene "Code Duplication" finding while preserving one named case per rejected input.
The README's fast-feedback checklist still described linting as Clippy only, while `make lint` now also runs the Whitaker Dylint suite. Document the `make lint` behaviour and the whitaker-installer provisioning step so that contributors do not pass locally and then hit CI-only failures.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
1 participant
Summary
This pull request adopts the Whitaker Dylint suite (v0.2.5) in the lint gate and continuous integration, as part of the estate-wide rollout following leynos/netsuke#410. The suite now runs alongside Clippy in
make lint, and CI installswhitaker-installer(cached, with acargo binstall-or-build fallback) before the lint step.All findings the suite reported were fixed rather than suppressed; no
dylint.tomlexclusions were required:mainso construction errors propagate instead of panicking inside the#[tokio::main]expansion (no_expect_outside_tests).cap_std::fs::Dir::create_ambient_dir_all, making the server's single ambient filesystem operation explicit, and storage test fixtures write through a capability-scopedDirhandle (no_std_fs_operations).usertest helpers returnanyhow::Resultand tests consume them with?, usinganyhow::ensure!because the crate deniesclippy::panic_in_result_fn(no_unwrap_or_else_panic).//!inner doc comment (module_must_have_inner_docs).Review walkthrough
WHITAKERtool variable and appends the suite to thelinttarget after Clippy.?andensure!.cap-stddependency.Validation
make check-fmt— passed.make lint— passed (Clippy with-D warningspluswhitaker --all -- --all-targets --all-featureswithRUSTFLAGS="-D warnings").make typecheck— passed.make test— passed (50 tests, 0 failures).make markdownlint— passed.make nixie— passed.mbake validate Makefile— valid syntax.