[FR]: lint_clippy_aspect could consume Cargo [lints] / rules_rust lint_config

[rbtcollins]

Problem

lint_clippy_aspect accepts a clippy_flags list for setting lint levels (e.g. -Dwarnings, -Dclippy::disallowed_methods, -Aclippy::new_without_default).

These flags duplicate configuration that, in modern Rust toolchains, lives in Cargo.toml's [lints.clippy] / [workspace.lints.clippy] section (stable since Rust 1.74 / Cargo 0.75).

In a hybrid Bazel + cargo workspace this means lint levels must be maintained in two places:

• Cargo.toml [workspace.lints.clippy] — what cargo / rust-analyzer / IDE clippy invocations see
• linters.bzl clippy_flags = [...] — what lint_clippy_aspect applies in Bazel

Drift between the two is silent: a lint allowed in one is denied in the other, and contributors only discover it when CI disagrees with their editor.

bazelbuild/rules_rust natively supports the [lints] table from Cargo.toml.

load("@rules_rust//cargo:defs.bzl", "extract_cargo_lints")

extract_cargo_lints(name = "my_lints", manifest = "Cargo.toml")

rust_library(
    name = "my_lib",
    srcs = ["src/lib.rs"],
    lint_config = ":my_lints",  # plumbs lint levels into rustc AND rust_clippy
)

rust_clippy (the rules_rust native rule) honors lint_config via deps. But lint_clippy_aspect (this repo) is a separate codepath and ignores it.

Proposal

lint_clippy_aspect could pick up clippy lint levels from one of:

1. The aspected target's lint_config attribute (if it's a rust_library / rust_binary / rust_test with one set), and merge those flags with clippy_flags.
2. Or accept an extract_cargo_lints target directly as an aspect parameter, e.g. cargo_lints = "//:workspace_lints", and apply it to every aspected Rust target.

[dzbarsky]

See #846 - extract_cargo_lints doesn't even exist in rules_rs, instead cargo_lints is in the generate external repo's workspace section (though that can be improved if needed).