Skip to content

Latest commit

 

History

History
50 lines (38 loc) · 2.25 KB

File metadata and controls

50 lines (38 loc) · 2.25 KB

init4 custom lints

Custom dylint lints for init4 Rust projects.

Structure

Each lint is a standalone crate under its own directory (e.g. instrument-fields/). Each crate has its own Cargo.toml, rust-toolchain.toml, and [workspace] - they are not members of a shared workspace.

Toolchain

All lint crates are pinned to nightly-2026-03-17 for compatibility with dylint_linting 5.0.0. The .cargo/config.toml in each crate sets the dylint-link linker. Both cargo-dylint (5.0.0) and dylint-link (5.0.0) must be installed to build.

CI

  • .github/workflows/ci.yml - builds and tests the lint crates themselves.
  • Consumer repos get linting automatically via the dylint job in init4tech/actions rust-base.yml. That workflow checks out this repo, builds the lint libraries, and runs them via DYLINT_LIBRARY_PATH.
  • Repos opt out by adding [workspace.metadata.dylint] skip = true to their Cargo.toml.

Adding a new lint

  1. Create a new directory at the repo root (e.g. my-lint/).
  2. Copy the structure from instrument-fields/ - Cargo.toml, .cargo/config.toml, rust-toolchain.toml, src/lib.rs, and ui/ test directory.
  3. Use declare_pre_expansion_lint! for lints that inspect proc-macro attributes (like #[instrument]), or declare_early_lint! / declare_late_lint! otherwise.
  4. Add a UI test under ui/ and run cargo test to generate the .stderr file (copy it from the path shown in the test failure output).
  5. Add the new crate to .github/workflows/ci.yml.
  6. Add the new lint name to the RUSTFLAGS deny list and a DYLINT_LIBRARY_PATH entry in the dylint job in init4tech/actions rust-base.yml.
  7. Update CLAUDE.md and README.md to document the new lint.

Modifying a lint

When changing lint behaviour, diagnostic messages, or adding new cases:

  1. Update src/lib.rs with the change.
  2. Update or add UI test cases in ui/bare_fields.rs (or equivalent).
  3. Rebuild (cargo build) and re-run tests (cargo test).
  4. The test will fail and print the path to the actual stderr - copy it over the existing .stderr file, then re-run cargo test to confirm it passes.
  5. Update CLAUDE.md and README.md if the change affects documented behaviour.