Repository navigation
ci(dylint): Dylint job is red on main — alias-loop workaround fails, so NO custom lints are enforced #964
Description
Context
The Dylint workflow check is failure on main HEAD (and on every PR — I saw it fail on #946, #948, #949, #956, #958, #961, #963). The "Run dylint over workspace" step exhausts its retry loop:
Error: Could not find `.../target/dylint/libraries/nightly-2026-03-26-x86_64-unknown-linux-gnu/release/libban_bare_reqwest@nightly-2026-03-26-x86_64-unknown-linux-gnu.so` despite successful build
... (same for ban_raw_subprocess, ban_manual_slash_normalize, ban_print_in_production, ban_raw_path_prefix_compare, and the rest)
echo "::error::cargo dylint did not succeed after ${max_attempts} attempts"
The workaround loop in .github/workflows/dylint.yml (aliasing cargo's bare <name>.<ext> to the <name>@<toolchain>.<ext> cargo-dylint 5.0.0 expects) is not converging — every lint library fails the @<toolchain> lookup "despite successful build", across all ~24 lints.
Impact
None of the custom dylints are actually enforced in CI. They compile and their unit tests pass, but the workspace-wide cargo dylint --all run never completes green, so a violation would not fail CI. The guardrails (ban_raw_subprocess, ban_std_pathbuf, ban_manual_slash_normalize, the new ban_raw_path_prefix_compare, etc.) are dormant.
Proposal
- Diagnose why the alias loop doesn't converge under the pinned cargo-dylint 5.0.0 + custom driver (does cargo-dylint rebuild and re-emit bare names each attempt, wiping the aliases? is the library dir path wrong?).
- Likely fixes: bump cargo-dylint to a version that emits
@<toolchain>-suffixed libraries natively, or alias once up-front and prevent the rebuild, or point--library-pathat the aliased copies.
Acceptance criteria
-
Dylintcheck is green on main. - A deliberate violation of any lint (e.g. a raw
Command::spawnorPath::starts_withadded to acrates/*/srcfile) fails the Dylint check.
Decisions
- Priority: P2 — CI enforcement of a growing lint suite is silently off; new violations land unblocked. Found while adding
ban_raw_path_prefix_compare(feat(dylint): ban raw Path::{starts_with, strip_prefix} so the #952 cache-key mistake can't recur #963).
Activity
zackees commentedon Jul 5, 2026
Diagnosis update (two CI attempts)
Confirmed the failure and narrowed the root cause; the post-hoc alias loop cannot fully fix this.
What the alias loop does and why it can't converge: cargo-dylint 5.0.0 builds each lint lib to the bare name `lib.so`, then its own post-build check (inside a single `cargo dylint` invocation) immediately looks for `lib@.so` and errors "could not find ... despite successful build". The workflow's alias loop only runs after `cargo dylint` exits, so on every retry cargo-dylint rebuilds and re-fails at build time before the aliases are ever consulted.
Attempt 1 (cp → symlink, PR #973, closed): switching the alias from `cp` to a relative symlink moved the failure from attempt 2 → attempt 25 (the symlink tracks the fresh bare lib instead of going stale), but it still ends red because the aliases are consulted too late. So this is a genuine-but-insufficient improvement.
Real root cause / path forward: the `@` suffix is supposed to be produced at link time by `dylint-link`, not patched in afterward. The lint-crate build isn't using `dylint-link` as its linker, so the bare name is emitted and cargo-dylint's build-time check fails. The fix is one of:
Both need dedicated CI iteration (each Dylint run is ~7-10 min building the rustc-dev tree). Flagging as needing a focused session rather than incremental guessing. Until then the `ban_raw_subprocess` / `ban_raw_path_prefix_compare` (#963) lints are authored but not enforced in CI.
zackees commentedon Jul 6, 2026
Config fix landed on PR #989 (branch
fix/964-dylint-link) — all 25 lints now build with @toolchain names and run. Remaining: fix/allowlist the real violations enforcement surfaced (Dylint check still failing). Full state + local-dylint repro recipe in #990.ci(dylint): wire dylint-link linker for all lint crates so libs get @…