feat: Migrate clippy to rules_rs

[dzbarsky]

rules_rs is (in my biased opinion) a more ergonomic and cleaner ruleset that avoids many of the pain points associated with rules_rust usage. It's also a better bzlmod citizen because it doesn't force registration of unwanted toolchains and lead to many unwanted downloads.

Currently rules_rs users who pull in rules_lint get the rules_rust bazel_dep and are unable to use the functionality here, while also being forced to register toolchains they don't want or need. I want to be able to recommend rules_lint to my users rather than telling them this ruleset doesn't interop with rules_rs. For example: hermeticbuild/rules_rs#97

Migration

Existing rules_rust users are encouraged to migrate to rules_rs to realize the benefits, though they can also make the new clippy support work for them via the following the rules_rs setup instructions, specifically:

adding the following MODULE.bazel snippet

bazel_dep(name = "rules_rs", version = "0.0.61")
toolchains = use_extension("@rules_rs//rs/toolchains:module_extension.bzl", "toolchains")
toolchains.toolchain(
    edition = "2024",
    version = "1.92.0",
)
use_repo(toolchains, "default_rust_toolchains")
register_toolchains("@default_rust_toolchains//:all")

Configuring their --host_platform in .bazelrc if they are on Windows or Linux (Mac should just work):

• .bazelrc config
• platform definitions

[aspect-workflows]

Bazel 7 (Test)

All tests were cache hits

6 tests (100.0%) were fully cached saving 2s.

---

Bazel 8 (Test)

All tests were cache hits

6 tests (100.0%) were fully cached saving 1s.

---

Bazel 9 (Test)

All tests were cache hits

6 tests (100.0%) were fully cached saving 1s.

[jbedard]

omg... why is this suddenly required? 🤦

[dzbarsky]

this is what i was mentioning on slack...transitive rules_cc bump bumps protobuf, which is no longer compatible with the version expected in this go module upstream. But we don't even need their protos so just kill them. Gazelle should be configured like this by default...

[jbedard]

What's less code... this gazelle override or a single_version_override for protobuf?

[dzbarsky]

I think it's about the same. We need an override in each example module just like this... Happy to swap if you prefer

[jbedard]

But single_version_override() on protobuf avoids any use of gazelle? It would just be:

# Explain WTF this is for in one line comment
single_version_override(module_name = "protobuf", version = "X")

?

[dzbarsky]

not quite that simple, you would first need to add bazel_dep(protobuf) and then be able to override. but yeah i suppose it's a few lines shorter. Sounds like you'd prefer I swap, i can try

[jbedard]

You can pin versions without direct deps on them actually, but it will fail if the dep doesn't exist in your dep graph.

[dzbarsky]

ah, maybe that's what i was thinking of, thanks for reminding me

[jbedard]

revert