Bump the Dylint dependency binaries to 6.0.1

[leynos]

Summary

Bumps the Dylint dependency binaries from cargo-dylint/dylint-link 4.1.0 to
6.0.1, and the Makefile's local install pins from 5.0.0 to 6.0.1.

This is a standalone-safe prerequisite for the forthcoming toolchain
migration to nightly-2026-05-28. Dylint 6 works on the current pin
(nightly-2025-09-18) — the suite's own tests already build UI drivers with
dylint_testing 6.0.1 — but 4.1.0 and 5.0.0 cannot build a driver on newer
nightlies: dylint_driver ≤ 5.0.0 fails to compile there because
ParseSess::env_depinfo/file_depinfo were removed upstream (E0609,
verified empirically). Landing this first means the rolling release carries
6.0.1 dependency binaries before the pin flips, so consumer CI never sees a
driver that cannot build.

Review walkthrough

• installer/dependency-binaries.toml — the single source of truth for the
  prebuilt dependency binaries; both entries move to 6.0.1. Changing this
  file auto-triggers the dependency-binary rebuild leg of the rolling
  release.
• Makefile — CARGO_DYLINT_VERSION/DYLINT_LINK_VERSION move
  5.0.0 → 6.0.1 for local cargo install paths.
• installer/src/{deps/tests.rs,tests.rs} — mock command expectations that
  assert the version sourced from the embedded manifest.
• installer/src/dependency_binaries/{manifest.rs,install/tests.rs} —
  assertions against the embedded manifest, plus doc examples and inline
  fixtures kept in step for consistency.

The Python workflow tests use their own fixture manifests and are
unaffected.

Validation

• env -u WHITAKER make check-fmt — clean.
• env -u WHITAKER make lint — clean.
• env -u WHITAKER make test — full suite green.
• env -u WHITAKER make markdownlint — clean.
• cargo-dylint 6.0.1 verified end-to-end on nightly-2026-05-28: its driver
  builds and runs the rebuilt suite correctly on a toy crate, while 5.0.0
  fails with E0609 on ParseSess fields.

[sourcery-ai]

Sorry @leynos, you have reached your weekly rate limit of 500000 diff characters.

Please try again later or upgrade to continue using Sourcery

[coderabbitai]

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in: 47 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 @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

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 configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 8d5d8194-fc79-4b75-9da9-a35dd471478f

📥 Commits

Reviewing files that changed from the base of the PR and between 4213d21 and 85c6091.

📒 Files selected for processing (6)

• Makefile
• docs/developers-guide.md
• docs/publishing.md
• scripts/install-dylint-tools.sh
• tests/workflows/test_install_dylint_tools.py
• tests/workflows/test_publish_check_provisioning.py

Walkthrough

Update the pinned cargo-dylint and dylint-link versions to 6.0.1, make publish-check select matching tool versions, and align installer metadata, archive names, fallback URLs, command expectations, fixtures, tests, and documentation.

Changes

Dependency version update

Layer / File(s)	Summary
Update dependency version pins Makefile, installer/dependency-binaries.toml, docs/developers-guide.md	Set configured, manifest, and documented example versions for cargo-dylint and dylint-link to 6.0.1.
Match publish-check tool versions Makefile	Check installed dylint tool versions, install mismatches into a per-run temporary directory, and add its bin directory to PATH.
Align installer expectations installer/src/dependency_binaries/..., installer/src/deps/tests.rs, installer/src/tests.rs	Update archive names, manifest fixtures, fallback URLs, cargo installation arguments, parameterised assertions, and CLI test expectations to reference 6.0.1.

Sequence Diagram(s)

sequenceDiagram
  participant PublishCheck
  participant InstalledTools
  participant CargoInstall
  PublishCheck->>InstalledTools: Check dylint tool versions
  InstalledTools-->>PublishCheck: Return installed versions
  PublishCheck->>CargoInstall: Install mismatches at 6.0.1 into a temporary root
  CargoInstall-->>PublishCheck: Return temporary bin directory
  PublishCheck->>InstalledTools: Use temporary tools through PATH

Loading

Poem

Pin tools to six-point-one,
Check each binary, one by one.
Install mismatches in a fresh space,
Let tests and archives keep pace.
Build and publish, neatly done.

---

Caution

Pre-merge checks failed

Please resolve all errors before merging. Addressing warnings is optional.

• Ignore

❌ Failed checks (3 errors, 2 warnings, 1 inconclusive)

Check name	Status	Explanation	Resolution
Testing (Overall)	❌ Error	The new Makefile version-mismatch/temp-dir logic has no test; current checks only verify the CI step exists and unit tests assert fixed install commands.	Add a test that simulates stale installed Dylint tools and asserts publish-check installs pinned versions into the temp dir, updates PATH, and fails on install errors.
Unit Architecture	❌ Error	Guard publish-check with set -e or explicit exits; the current cargo-dylint/cargo install checks can fail silently and leave the stale PATH active.	Add fail-fast shell flags or || exit 1 after each install, and append the temp bin dir to PATH only after both commands succeed.
Security And Privacy	❌ Error	publish-check still ignores failed cargo-dylint/dylint-link installs, so the old PATH can satisfy later steps and bypass the pinned-tool check.	Add set -eu (or explicit exits) before the install block so any failed install aborts the target and PATH never falls back to stale tools.
Domain Architecture	⚠️ Warning	publish-check still lacks set -e/guards; failed cargo install at lines 252/255 can be ignored, so the command does not honestly enforce pinned-tool installation.	Add set -eu to the recipe or append || exit 1 after each install, then append the temp bin dir to PATH only after both installs succeed.
Concurrency And State	⚠️ Warning	publish-check mutates PATH and installs into a temp dir without set -e or explicit guards, so failed installs can leave stale state in place.	Add set -eu or explicit exits after each install, and cover the failed-install path so the target cannot continue with stale tools.
User-Facing Documentation	❓ Inconclusive	Need repository evidence before deciding whether the change is user-facing.	Inspect the changed files and the existing users guide, then judge whether any end-user behaviour was added or altered.

✅ Passed checks (14 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately summarises the dependency-binary version bump in this change set.
Description check	✅ Passed	The description clearly matches the dependency-binary and Makefile version updates in the pull request.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Developer Documentation	✅ Passed	The developers guide now documents the bump with version = "6.0.1", and the execplan marks the guide update complete.
Module-Level Documentation	✅ Passed	Pass: every changed Rust module starts with a //! doc comment stating its purpose; manifest.rs also names its TOML source of truth.
Testing (Unit And Behavioural)	✅ Passed	Only docs/developers-guide.md changed in this commit; no code or test behaviour is affected, so the testing check is not applicable.
Testing (Property / Proof)	✅ Passed	PASS: The PR only bumps fixed tool versions and updates example-based tests/docs; it does not introduce a new range-based invariant or lemma that needs property/proof coverage.
Testing (Compile-Time / Ui)	✅ Passed	Accept that no trybuild/snapshot harness is needed: the PR only retunes version strings and keeps focused unit/behaviour assertions, with no new compile-time boundary or broad UI transcript.
Observability	✅ Passed	Only version pins, tests, docs, and a Makefile install check changed; no new runtime/async operation, so extra observability is not required.
Performance And Resource Use	✅ Passed	PASS: the PR only bumps pinned versions and updates tests/docs; the Makefile’s checks are bounded to two tools with one temp dir and no hot-path regression.
Architectural Complexity And Maintainability	✅ Passed	PASS: Keep it as direct version bumps and shell-level tool checks; no new abstraction, layer, dependency edge, or hidden registry was introduced.
Rust Compiler Lint Integrity	✅ Passed	The touched Rust hunks only update version strings and a test parametrisation; no new #[allow]/#[expect] suppressions or clone-heavy ownership work were added.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch bump-dylint-6

---

_{Comment @coderabbitai help to get the list of available commands.}

[pandalump]

@coderabbitai review

[coderabbitai]

✅ Action performed

Review finished.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[leynos]

Review feedback addressed, rebased onto main (b10fc19):

• 25e56de — publish-check validates installed cargo-dylint/dylint-link versions against the pinned CARGO_DYLINT_VERSION/DYLINT_LINK_VERSION, installing mismatched or missing tools into an isolated per-run directory that is prepended to PATH. dylint-link is probed via cargo install --list because its --version flag forwards to the underlying linker.
• aa328ed — the manifest pin test is parameterized over both cargo-dylint and dylint-link with rstest cases, so neither pin can drift without a failure.
• 4213d21 — the developers-guide dependency-binary example now shows 6.0.1, matching the committed manifest.

Gates on the rebased branch: check-fmt, lint, test (1454/1454), markdownlint — all green.

[pandalump]

@coderabbitai resume

[coderabbitai]

✅ Action performed

Reviews resumed.

[leynos]

Review-round summary (verified per finding before acting):

• Fail-fast (inline, Unit Architecture, Security and Privacy, Domain Architecture, Concurrency and State) — valid, and broader than reported: nothing in the continued block propagated failures, so even a failing nextest run or git clone would not have stopped the gate. Fixed in ef07e94 with set -eu plus an explicit guard on the cd into the cloned tree, which as a non-final &&-list member was exempt from set -e and would otherwise have silently skipped the dylint build step.
• Testing — valid. The provisioning logic is now scripts/install-dylint-tools.sh (the repository's tested-script convention), with behavioural tests in tests/workflows/test_install_dylint_tools.py running it under stubbed cargo/cargo-dylint binaries: matching tools install nothing, stale or missing tools install the pins into the isolated root, a failed install aborts non-zero, and the argument contract is enforced (05b1636).
• User-Facing Documentation (inconclusive) — resolved as not user-facing: neither README.md nor docs/users-guide.md mentions publish-check or any pinned tool version (the users' guide refers only to "the version recorded in the dependency manifest"). publish-check is documented solely in the maintainer runbook, which now describes the fail-fast provisioning behaviour, with a cross-reference from the developers' guide prerequisites (ad973ad).

Gates on the branch: check-fmt, lint, test (1454 passed), markdownlint, and the new pytest suite — all green.

[leynos]

@coderabbitai Please suggest a fix for this issue and supply a prompt for an AI coding agent to enable it to apply the fix. Include the file and symbol names indicated in the issue at the head of your response. Ensure that this is validated against the current version of the codegraph.

If further refinement to address this finding would be deleterious, please supply a clear explanatory one to two paragraph markdown message I can paste into the CodeScene web ui's diagnostic suppression function so this diagnostic can be silenced.

tests/workflows/test_install_dylint_tools.py

Comment on lines +103 to +119

def test_matching_tools_install_nothing(tmp_path: Path) -> None:
    """Matching system versions must not trigger any install."""
    stub_dir = tmp_path / "bin"
    stub_dir.mkdir()
    _write_stub(
        stub_dir,
        "cargo-dylint",
        f'echo "cargo-dylint {CARGO_DYLINT_VERSION}"',
    )
    _write_cargo_stub(stub_dir, installed_dylint_link=DYLINT_LINK_VERSION)
    tools_root = tmp_path / "tools"

    result = _run_script(stub_dir, tools_root)

    assert result.returncode == 0, result.stderr
    assert _install_log(stub_dir) == ""
    assert not tools_root.exists()

❌ New issue: Code Duplication
The module contains 2 functions with similar structure: test_matching_tools_install_nothing,test_missing_dylint_link_installs_pin

[leynos]

@coderabbitai Have the following now been resolved?

installer/src/dependency_binaries/manifest.rs (1)

363-369: 🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick win
Test the dylint-link version as well.
This assertion protects only the cargo-dylint pin, while the manifest also changes dylint-link to 6.0.1. Parameterize the existing test for both binaries, or verify an equivalent existing test, so a partial version update cannot pass unnoticed.

Parameterize the manifest lookup test

-    #[test]
+    #[rstest]
+    #[case("cargo-dylint", "cargo-dylint", "6.0.1")]
+    #[case("dylint-link", "dylint-link", "6.0.1")]
-    fn find_dependency_binary_returns_matching_package() {
-        let tool = find_dependency_binary("cargo-dylint")
+    fn find_dependency_binary_returns_matching_package(
+        #[case] package: &str,
+        #[case] binary: &str,
+        #[case] version: &str,
+    ) {
+        let tool = find_dependency_binary(package)
             .expect("embedded manifest should stay parseable")
             .expect("tool should exist");
-        assert_eq!(tool.binary(), "cargo-dylint");
-        assert_eq!(tool.version(), "6.0.1");
+        assert_eq!(tool.binary(), binary);
+        assert_eq!(tool.version(), version);
     }

As per coding guidelines, all new functionality and behavioural changes require rigorous, non-vacuous tests.

🤖 Detailed instructions

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @installer/src/dependency_binaries/manifest.rs around lines 363 - 369, Extend
the existing find_dependency_binary_returns_matching_package test to cover both
cargo-dylint and dylint-link at version 6.0.1. Parameterize the test inputs for
package, binary, and expected version, and use those values in the lookup and
assertions so either manifest pin cannot change without failing the test.

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo '== manifest.rs outline =='
ast-grep outline installer/src/dependency_binaries/manifest.rs --items all --view expanded

echo
echo '== target test and rstest context =='
rg -n -C 12 '\b(find_dependency_binary_returns_matching_package|rstest)\b' \
  installer/src/dependency_binaries/manifest.rs

echo
echo '== Dylint manifest entries =='
rg -n -C 4 '^(package|binary|version) = "(cargo-dylint|dylint-link|6\.0\.1)"$' \
  installer/dependency-binaries.toml

Length of output: 4891

---

@leynos Resolved — installer/src/dependency_binaries/manifest.rs::find_dependency_binary_returns_matching_package.

Verify Lines 363–375: the test is now parameterized with distinct cargo-dylint and dylint-link cases. It performs the lookup using the supplied package and asserts both the binary name and version (6.0.1).

Verify installer/dependency-binaries.toml: both manifest entries are currently pinned to 6.0.1. A partial update, missing entry, changed binary mapping, or version drift for either Dylint dependency now fails this test. No further refinement is required.

[leynos]

@coderabbitai Have the following failed checks now been resolved?

If further work is required, please provide an AI agent prompt for the remaining work to be done to address these failures.

Do not treat warnings as optional or aspirational. Where a change is out of scope for this PR, propose a GitHub issue unless one exists already. (Treat documentation and validation coverage as in scope).

❌ Failed checks (3 errors, 2 warnings, 1 inconclusive)

Check name	Status	Explanation	Resolution
Testing (Overall)	❌ Error	The new Makefile version-mismatch/temp-dir logic has no test; current checks only verify the CI step exists and unit tests assert fixed install commands.	Add a test that simulates stale installed Dylint tools and asserts publish-check installs pinned versions into the temp dir, updates PATH, and fails on install errors.
Unit Architecture	❌ Error	Guard publish-check with set -e or explicit exits; the current cargo-dylint/cargo install checks can fail silently and leave the stale PATH active.	Add fail-fast shell flags or `
Security And Privacy	❌ Error	publish-check still ignores failed cargo-dylint/dylint-link installs, so the old PATH can satisfy later steps and bypass the pinned-tool check.	Add set -eu (or explicit exits) before the install block so any failed install aborts the target and PATH never falls back to stale tools.
Domain Architecture	⚠️ Warning	publish-check still lacks set -e/guards; failed cargo install at lines 252/255 can be ignored, so the command does not honestly enforce pinned-tool installation.	Add set -eu to the recipe or append `
Concurrency And State	⚠️ Warning	publish-check mutates PATH and installs into a temp dir without set -e or explicit guards, so failed installs can leave stale state in place.	Add set -eu or explicit exits after each install, and cover the failed-install path so the target cannot continue with stale tools.
User-Facing Documentation	❓ Inconclusive	Need repository evidence before deciding whether the change is user-facing.	Inspect the changed files and the existing users guide, then judge whether any end-user behaviour was added or altered.

[leynos]

Integration coverage added in f37b466: tests/workflows/test_publish_check_provisioning.py runs the real publish-check recipe with every external command stubbed and recording to an invocation log. The two behavioural scenarios requested: (1) a stale system cargo-dylint provisions the pin into the isolated root, and the subsequent Dylint-facing command demonstrably resolves …/dylint-tools/bin/cargo-dylint ahead of the stale binary on PATH; (2) a failed install exits the target non-zero with the log proving no git clone, per-lint release build, Dylint invocation, or cargo package ever ran. No refactor of the recipe was needed — full command stubbing exercises the production command order and fail-fast semantics exactly as shipped. The direct script tests remain as unit-level coverage. Focused pytest (10 passed across both modules), ruff check/format, make -n publish-check, and markdownlint are all clean.

[codescene-access]

No quality gates enabled for this code.