[leynos]

Summary

This change adds opt-in --no-driver-build and the corresponding default-false
library option. Binary-only deployments can require a pre-provisioned compiler
driver instead of allowing a source build when the cached driver is missing,
outdated, or cannot be queried or parsed.

Ordinary defaults remain unchanged. The existing comparison accepts a cached
driver whose reported version is at least the Dylint version; this change
preserves that policy without adding compatibility validation. The existing
--no-build option continues to control metadata library builds independently.

Review walkthrough

• Start with the driver decision: refusal and the original build callback share the same boundary.
• Review the library option and CLI conversion for default-false propagation through checking and listing.
• Review the injected tests, CLI contracts, and public CLI regression.

Injected tests cover all three refusal reasons, current-driver reuse, default
rebuilding and build-error propagation. The public regression uses isolated
temporary driver storage and child-only executable lookup, requiring the
specific missing-driver refusal without providing a compiler or cached driver.
Parsing and I/O setup propagate their errors.

The seventh path is a comment-only repair in the
test support helper:
it describes the historical examples directory without leaving a stale literal
path for the repository's path-comment lint. Runtime helper behaviour is
unchanged. CLI error assertions put expected enum values first; the public
regression keeps real I/O fallible and verifies no tool was provisioned.

Listing uses cargo dylint list --no-driver-build ...: options follow the final
subcommand, preserving the existing parser rule.

Validation

Published head: f91ed3ce50898bf503912d98d0679e60fc61caa0.
Its parent is 25c51a55124a18a9aa2de673ade0a965ae640d78; its tree is
6bd2f27c01ded18834314041fb2d8888f8ebc7d7. The complete seven-file patch has
SHA-256 0498026d8ba5e52f392dea414c839321e6d337f233f6ba790a99605c0d0d6be0.
The committed tree is byte-identical to the independently checked candidate.

All eight commands passed sequentially on that tree on 18 October 2026. Each
compiler/test command and its logging process separately returned zero:

Exact local command	Result
cargo clippy -p dylint -p cargo-dylint --all-targets --all-features -- -D warnings	Passed
cargo test -p dylint --lib no_driver_build_tests	4 passed, 0 failed, 2 filtered
cargo test -p cargo-dylint --bin cargo-dylint no_driver_build	4 passed, 0 failed, 1 filtered
cargo test -p cargo-dylint --bin cargo-dylint verify_cli	1 passed, 0 failed, 4 filtered
cargo test -p cargo-dylint --test no_driver_build	1 passed, 0 failed
cargo +nightly fmt --all -- --check	Passed
cargo test -p cargo-dylint --test ci rustdoc_prettier -- --exact --nocapture	1 passed, 0 failed, 25 filtered
cargo test -p cargo-dylint --test ci lint -- --exact --nocapture	1 passed, 0 failed, 25 filtered

The final self-lint contract
completed across nine directories: the root, driver, linting utilities, general,
supplementary and restriction examples, the Clippy testing examples, and the
experimental missing-doc-comment and derive-opportunity examples. Its complete
log is SHA-256 88e9eb10e9dd8d648222ba558b6a3152754b78603f9590307a36a84e220a7415.
These are the eight selected local gates, not a claim that every upstream test
or platform has run locally. Earlier failing or different-tree runs remain
historical evidence.

The previous published head 1c1c710cdedfbe5f269962ae24e08b43e27450a9
had failed Ubuntu cargo-dylint-ci and all-checks jobs in
hosted run 38824110437.
Those results do not validate this replacement head. Fresh hosted checks,
the upstream Ubuntu/macOS/Windows matrix and review remain pending; this PR
remains draft.

The live default branch was master at
f4e28c951ed53f565e1400f374f4321100de2765 when publication was verified.
The immutable comparison from the local base is five commits ahead with no
changed file overlapping these seven paths or the self-lint harness. Dependency
and shared-lint changes still require fresh hosted integration evidence. Local
base validation does not establish a successful merge-tip build. Publication
does not waive required checks or justify a merge of a stale green commit.

The earlier CLA-assistant result could not associate the commit identity with
the account; it did not establish whether legal terms were signed. This draft's
author and committer metadata now use the existing public identity associated
with leynos, verified against a public commit from the same account. Its tree,
parent and commit message are unchanged. No legal terms were signed, no account
settings were changed, and no CLA recheck was requested. Fresh hosted checks
are pending for this new head; earlier hosted results do not transfer. Upstream
merge and release remain maintainer actions.

Compatibility and dependencies

The options module convention
classifies additive fields as non-breaking and recommends struct-update syntax.
The new field follows that convention; downstream exhaustive struct literals
still need a source update. The public driver lookup signature is unchanged.

This is an external prerequisite for Whitaker's driver asset/provisioning
work. The existing
root CLI work owns its invocation
integration. Upstream merge and a release exposing this option, driver assets,
installer provisioning and consumer adoption remain separate prerequisites.
This PR does not claim a complete binary-only consumer rollout.

Issue #2131 and
PR #2132 concern supplied Clippy
symbols for driver builds without network access. This change controls whether
a driver build may happen at all; it does not duplicate or close that work.

References

• Existing driver build decision
• Upstream contribution convention
• Existing CI matrix
• Consumer execution session

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[smoelius]

@leynos If --no-driver-build is passed and a compatible driver is not already built, cargo-dylint returns an error? Is that the intent?

I am open to adding such a feature, but can I ask what motivated this?

[leynos]

@smoelius Yes. With --no-driver-build, a missing, stale, or unverifiable compiler driver should produce an actionable error instead of starting a driver source build. An already compatible driver remains usable, and the default behavior is unchanged. This is separate from --no-build, which controls building lint libraries.

The motivation is binary-only provisioning for Whitaker CI. Its installer can refuse source fallback while acquiring tools, but a later cargo dylint invocation can still implicitly compile a missing compiler-coupled driver. We need that missing published asset to fail visibly rather than turn a supposedly binary-only gate into a source build. The asset/provisioning work is tracked in leynos/whitaker#496; this flag supplies the runtime refusal boundary.

I am validating the revised regression tests before pushing the updated candidate. The current PR head does not yet contain those revisions, and I am not claiming the pending checks are green.

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-18T06:13:53.285345Z	f91ed3c	Draft marked ready

ℹ️ 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" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[smoelius]

The motivation is binary-only provisioning for Whitaker CI. Its installer can refuse source fallback while acquiring tools, but a later cargo dylint invocation can still implicitly compile a missing compiler-coupled driver.

Thanks for your answer. I'm still not quite following, though. "Acquiring tools" could cause a driver to be built? What is meant by the phrase "acquiring tools"?

I'll review this PR as soon as I can. In the meantime, could you sign the CLA?