Quick Setup

Install cargo-dylint and dylint-link:

cargo install cargo-dylint dylint-link

The simplest way to use Whitaker is via the standalone installer, which handles setup automatically:

cargo install whitaker-installer
whitaker-installer
whitaker --all

This:

1. Installs cargo-dylint and dylint-link if not present The installer first attempts to download pre-built dependency binaries from Whitaker's GitHub Releases page for the current platform. If the release asset is absent (HTTP 404 or 410), the installer skips cargo binstall and falls back directly to building from source with cargo install, pinned to the version recorded in the dependency manifest. If the release asset is present but the download fails for another reason, the installer falls back to cargo binstall when available and then to cargo install. When the source-build path is taken, the installer reports that it is falling back to Cargo, and on success it prints Installed <tool> from source with cargo install.. After installation, cargo-dylint is verified by running cargo dylint --version. dylint-link is never executed: it is a linker wrapper that forwards its arguments to the underlying linker, so it has no reliable self-reporting subcommand. A release artefact is trusted once its checksum, extraction, and executable permissions have been established, and a Cargo-managed copy is checked by resolving it on PATH and comparing the version Cargo recorded.
2. Clones the Whitaker repository to a platform-specific data directory
3. Builds the lint libraries
4. Creates whitaker and whitaker-ls wrapper scripts. whitaker invokes cargo dylint with the correct DYLINT_LIBRARY_PATH, and whitaker-ls lists installed Whitaker suite libraries
5. Ensures the pinned Rust toolchain and components are installed via rustup

After installation, run whitaker --all in any Rust project to lint it. Use whitaker-ls to list the installed Whitaker suite libraries.

On Windows, the installer's PATH check honours PATHEXT and falls back to the usual executable suffixes when PATHEXT is unset, so a normal Cargo-installed executable such as dylint-link.exe in %USERPROFILE%\.cargo\bin is located correctly and then matched against the version Cargo recorded for it, without needing a separate wrapper or manual environment-variable workaround.

• --cranelift — Tell the installer to add the rustc-codegen-cranelift component via rustup component add. The rustc-codegen-cranelift component is not included in the standard nightly toolchain, so enable --cranelift when a project or CI pipeline requires the Cranelift back-end and would otherwise need an explicit rustc-codegen-cranelift component-add step before running the installer.
• --skip-deps — Skip cargo-dylint/dylint-link installation check
• --skip-wrapper — Skip wrapper script generation (prints DYLINT_LIBRARY_PATH instructions instead)
• --no-update — Don't update existing repository clone

Add the following to the workspace Cargo.toml:

[workspace.metadata.dylint]
libraries = [
  { git = "https://github.com/leynos/whitaker", pattern = "whitaker_suite" }
]

Then run the lints:

cargo dylint --all

For reproducible builds, pin to a specific release tag or commit:

[workspace.metadata.dylint]
libraries = [
  { git = "https://github.com/leynos/whitaker", pattern = "whitaker_suite", tag = "v0.1.0" }
]

Or pin to a specific commit:

[workspace.metadata.dylint]
libraries = [
  { git = "https://github.com/leynos/whitaker", pattern = "whitaker_suite", rev = "abc123def456" }
]

Whitaker publishes a rolling pre-release tag that is continuously updated and overwritten on every push to main. It is intended for early adopters who want the latest available build outputs before the next stable release is cut.

Rolling releases are best-effort builds. If some matrix legs fail, Whitaker still publishes the artefacts that were built successfully. For example, a target-specific cargo-dylint archive may be missing from one rolling release even though other target archives were updated successfully. Do not assume that every supported target is present in every rolling release.

Stable releases differ from rolling: a stable tag is expected to contain the complete artefact set for the release. For production installs, pin to a stable release tag rather than consuming rolling.

Scripts or CI pipelines that consume rolling-release archives should verify that the required target archive exists before proceeding. Treat missing archives as an expected condition for rolling releases rather than assuming the artefact set is complete.

To load specific lints instead of the full suite, specify each lint explicitly:

[workspace.metadata.dylint]
libraries = [
  { git = "https://github.com/leynos/whitaker", pattern = "crates/module_max_lines" },
  { git = "https://github.com/leynos/whitaker", pattern = "crates/no_expect_outside_tests" }
]

Whitaker lints are divided into two categories:

• Standard lints are stable, well-tested, and included in the default suite. They are recommended for general use and have predictable behaviour.
• Experimental lints are newer or more aggressive checks that may produce false positives or undergo breaking changes between releases. They must be explicitly enabled.

The default whitaker_suite pattern includes only standard lints. Whitaker currently ships one experimental lint, rstest_helper_should_be_fixture, which is available only when experimental lints are enabled.

Via standalone installer

whitaker-installer --experimental

This enables experimental suite features when building whitaker_suite. To build experimental lints as individual libraries, combine it with --individual-lints. Explicit --lint requests for experimental lints also require --experimental; without that opt-in the installer rejects the request before building anything.