-
Notifications
You must be signed in to change notification settings - Fork 572
Description
When running rust_clippy_aspect as part of a rust-analyzer setup (following the example script), the clippy action fails hard on compilation errors. This prevents downstream aspects from collecting and surfacing diagnostics to the IDE, even though the .clippy.diagnostics file has been successfully written.
My setup differs from the example: I have a secondary aspect on top of rust_clippy_aspect that reads the .clippy.diagnostics file and cats it to stdout if it contains diagnostic messages, producing its output file only when there are no errors. This avoids having to scan the output base for .clippy.diagnostics files (which may be stale or irrelevant), and ensures diagnostics are always surfaced even when the action result is cached. The problem is that when a crate fails to compile, the upstream clippy action exits non-zero and the secondary aspect never runs.
Request: a build setting or toolchain attribute that causes the clippy action to always exit 0 — analogous to how some lint tools have a "report but don't fail" mode — so that diagnostics can be collected even when a crate fails to compile.
Current workaround: a repository rule that duplicates the entire *_tools repo and replaces bin/clippy-driver with a shell script wrapper that calls the real binary and unconditionally exits 0. This works but is fragile: it requires one instantiation per platform, duplicates the full toolchain repo, and will silently break if the upstream toolchain repo structure changes.