Publish and provision version-matched Dylint compiler-driver assets #496

Summary

The rolling Whitaker consumer has no binary-only route for Dylint's compiler-private dylint-driver on a cold cache. Dylint currently builds the driver when it is missing, stale, or cannot be inspected. The shared install-whitaker action's --no-source-fallback option covers installer provisioning; it does not guard the later cargo dylint driver lookup. Track this release and provisioning gap without claiming compliance.

Proposed owner: leynos.

The Dylint refusal guard is being prepared in draft Dylint PR #2133, currently at 1c1c710cdedfbe5f269962ae24e08b43e27450a9. It is neither merged nor released; its approved released interface remains a dependency. Producer preparation can proceed independently, while final qualification and consumer adoption require the approved released contract. Do not invent a version or pin the rolling Whitaker suite.

Ownership and existing work

Whitaker owns its rolling release assets and installer placement contract. Dylint owns the guard that refuses an absent, stale, invalid-version or uninspectable driver without building it. Release-tooling and manifest preparation for the asset can proceed independently, but a usable release and consumer adoption depend on validating it against the released guard and supported compiler/platform combinations.

The CLI/wrapper forwarding change belongs to the existing invocation owner, Whitaker PR #356 M2 or a narrow follow-up owned with that work. This issue tracks asset production, verification and provisioning; it does not duplicate wrapper or CLI implementation. Track the forwarding dependency in #356 after the Dylint interface is available. If the shared action needs a provisioning input, establish that only after the supported release interface and Whitaker launcher contract show it is necessary.

This work is distinct from Whitaker #403 (suite lint-library publication), #425 (provenance for installed lint artefacts), #460 (verification of the cargo-dylint helper executable), #499 (immutable suite pin/cache proposal, incompatible with the rolling-suite requirement), shared-actions #522 (merged installer source-fallback policy), and Dylint #2131/#2132 (build-time source acquisition). These do not publish or provision the compiler-driver cache asset. Do not close or repurpose them as if they did.

Required implementation

Prepare a distinct compiler-driver archive and verifiable manifest in Whitaker's rolling release pipeline. Keep this artifact separate from suite lint-library archives and from cargo-dylint/dylint-link helper binaries: they have different build products and lifecycles. The consumer must install a verified binary into the location Dylint resolves, <root>/<toolchain>/dylint-driver with the platform executable suffix (.exe on Windows), or coordinate an explicit upstream cache-path change.

Before releasing or adopting an asset, bind its identity and manifest to at least:

• the exact Dylint driver release/version;
• exact Rust compiler identity (immutable rustc commit/date and selected channel/toolchain alias);
• compiler-driver host triple/architecture and supported platform ABI, including the Linux glibc floor where applicable;
• archive digest and content identity; and
• expected installed path and executable name.

The compiler host is distinct from the target being linted. Existing Whitaker release matrix entries do not prove compiler-private driver compatibility on those platforms. Qualify combinations empirically and explicitly list unsupported combinations rather than inferring support from the suite archive matrix. The asset may be prepared independently, but its final identity and compatibility must be checked against the released Dylint guard/toolchain contract.

Keep the consumer binary-only and the Whitaker suite rolling with no suite-version pin. Neither consumer nor action may fall back to compiling the driver. Do not claim the shared action's installer fallback switch covers this separate runtime path.

Acceptance evidence

• Release tests reject an asset whose Dylint version, rustc identity, host/ABI, digest or manifest does not match the selected configuration.
• A cold-cache integration run installs the approved published asset at Dylint's resolved lookup path and completes the Whitaker lint invocation without compiling a driver.
• Negative cold-cache cases (missing, stale, mismatched, corrupt or uninspectable asset) fail closed with an actionable provisioning error and prove no source-build path ran.
• Platform qualification is recorded separately for each published host/toolchain combination; untested matrix members remain unsupported.
• Relocation qualification runs the installed driver with a different compiler sysroot and installation root while the producer home directory is unavailable. Source inspection found an absolute producer-sysroot RPATH; an archive and digest alone do not prove Unix loader or rustc_private portability. Verify the dynamic-library lookup and compiler-private ABI against the selected destination toolchain, and fail unsupported combinations closed.
• The invocation-owner change in Whitaker Add a root whitaker binary behind an internal library boundary (3.5.1) #356 M2 or its owner-approved follow-up forwards the released guard mechanism and preserves existing argv and exit status across supported shells. This is a tracked dependency, not duplicated implementation scope for this issue.

References

• Whitaker current wrapper at immutable main revision f7a5a93
• Dylint driver lookup/build at immutable revision 365fbd6
• Whitaker rolling downloader
• Whitaker rolling release publisher
• Shared installer action at immutable e693d81