[Bug]: aspect_rules_lint_rules_rust submodule is not consumable by downstream repos in 2.6.0

[vadikmironov]

What happened?

Summary

Thanks a lot for all the work on clippy aspect under #865. However, the new aspect_rules_lint_rules_rust module is currently impossible to bring in without patching upstream sources, which makes the documented migration path (load("@aspect_rules_lint_rules_rust//:clippy.bzl", ...)) unusable in practice.

The three blockers, in order:

1. Not published to BCR. https://github.com/bazelbuild/bazel-central-registry/tree/main/modules/aspect_rules_lint_rules_rust does not exist, so a plain bazel_dep(name = "aspect_rules_lint_rules_rust", version = "...") fails to resolve.
2. Excluded from every git archive output. .gitattributes at v2.6.0 contains: lint/rules_rust export-ignore and lint/rules_rust/** export-ignore . This strips the directory from the official release tarball (rules_lint-v2.6.0.tar.gz) and from GitHub's auto-generated refs/tags/v2.6.0.tar.gz. So archive_override cannot reach it via any URL on github.com.
3. git_override works, but the submodule's MODULE.bazel is only valid in-tree. Once cloned, it contains:
   bazel_dep(name = "aspect_rules_lint") # no version
   ...
   local_path_override(
   module_name = "aspect_rules_lint",
   path = "../..",
   )
   Since Bazel only honors *_override declarations in the root module, the local_path_override is silently dropped, leaving the versionless bazel_dep to fail.

Version

Development (host) and target OS/architectures:
lsb_release -d
Description: Debian GNU/Linux 13 (trixie)

Output of bazel --version:
bazel --version
bazel 8.7.0

Version of the Aspect rules, or other relevant rules from your
WORKSPACE or MODULE.bazel file:
current: 2.5.2
proposed: 2.6.0

Language(s) and/or frameworks involved:
Bazel, C++, Rust, Python

How to reproduce

### Repro

Any downstream MODULE.bazel that follows the new docs:
  bazel_dep(name = "aspect_rules_lint", version = "2.6.0")
  bazel_dep(name = "aspect_rules_lint_rules_rust", version = "0.0.0")
  git_override(
      module_name = "aspect_rules_lint_rules_rust",
      remote = "https://github.com/aspect-build/rules_lint.git",
      commit = "3f0c79fa75cc37e7dafbdb7e6005ad62b0b0775b",  # v2.6.0
      strip_prefix = "lint/rules_rust",
  )
  fails at main-repo-mapping with the error above.

Any other information?

Workarounds available to downstream users

• single_version_override(module_name = "aspect_rules_lint", version = "2.6.0") at the root, to satisfy the versionless bazel_dep from the submodule.
• git_override(... patches = [...]) to pin the version inside the submodule's MODULE.bazel.
• Vendor lint/rules_rust/ into the downstream repo.

All three force consumers to know upstream internals, which I suppose was not the goal of the split.

[vadikmironov]

Friendly reminder that this is still open — and all three blockers are still present at main HEAD (eff4e93), including after #846 landed.

Minimal repro: https://github.com/vadikmironov/repro_aspect_rules_lint_issue_879 — each blocker is a mutually-exclusive variant in MODULE.bazel, pinned at eff4e93, reproducible with just 'bazel mod graph' (no build or toolchains needed):

#1 — not on BCR (bazel_dep only):
ERROR: ... module aspect_rules_lint_rules_rust@0.0.0 not found in registries:

• https://bcr.bazel.build/modules/aspect_rules_lint_rules_rust/0.0.0/MODULE.bazel: not found

#2 — export-ignore strips the dir from archives (archive_override → GitHub archive/eff4e9396d….tar.gz):
Error extracting ...: Prefix "rules_lint-eff4e9396d…/lint/rules_rust" was given,
but not found in the archive. Here are possible prefixes for this archive:
"rules_lint-eff4e9396d…".

#3 — submodule's versionless bazel_dep + dropped local_path_override (git_override, which does contain the dir — export-ignore is archive-only):
ERROR: in module dependency chain -> aspect_rules_lint_rules_rust@_ -> aspect_rules_lint@_:
bad bazel_dep on module 'aspect_rules_lint' with no version.
Did you forget to specify a version, or a non-registry override?

The git_override (succeeds) vs archive_override (dir absent) contrast at the same commit isolates #2 to export-ignore rather than a missing feature.

On #846: I want to make sure I understand the intended path for existing rules_rust repos. The new aspect_rules_lint_rust module doesn't take bazel_dep(rules_rust) — it sources @rules_rust from rules_rs (use_extension("@rules_rs//rs:rules_rust.bzl", "rules_rust")) and unconditionally register_toolchains("@default_rust_toolchains//:all", "@llvm//toolchain:all"). For a repo already on canonical rules_rust with its own registered toolchains, bringing it in would add rules_rs to the graph, register a second (rules_rs, 1.92.0) Rust toolchain plus an llvm toolchain, and point the clippy aspect at a different @rules_rust/toolchain_type than the targets are built with. So it reads as the rules_rs path rather than a drop-in for rules_rust users. (It also reproduces #2 — .gitattributes adds lint/rust export-ignore — keeps the in-tree local_path_override, and isn't on BCR, so it isn't downstream-consumable yet either.)

So for rules_rust consumers, aspect_rules_lint_rules_rust still seems to be the intended module — is the plan to keep it as the rules_rust path and get it consumable, i.e. drop the export-ignore lines, publish to BCR, and version the submodule's bazel_dep?

cc @jbedard @JesseTatasciore — flagging for visibility, since blockers #1 (publish to BCR) and #2 (release-tarball export-ignore) look like packaging/release-side fixes rather than the aspect code itself. cc @dzbarsky as the #846 author, re: the rules_rust-vs-rules_rs question above.

Happy to test a candidate against the repro. Thanks for the work here!

[dzbarsky]

Apologies for the pain. I have been pushing to get this published but was advised to wait until bazel-contrib/publish-to-bcr#390 merged and released so the submodule could be properly published. So I believe the next step is publish a new release of the publish-to-bcr app. @jbedard @JesseTatasciore can you please help?

[dzbarsky]

Regarding the path forward for rules_rust users - the recommended way is to migrate to rules_rs. It should be drop-in compatible and you will get perf, hermeticity, and correctness improvements. However, even if you choose to not migrate, the lint module should still work transparently with rules_rs toolchains. As you note, it's a little silly to register both sets of toolchains, but it's necessary because rules_rust maintainers were not interested in sharing the toolchain types.

The existing aspect_lint_rules_rust module will be deleted once the aspect_lint_rust module is published to decrease maintenance burden. Unfortunatley rules_rust maintainers were not receptive to merging the processwrapper changes needed to make this linting integration work, which increases the maintenance burden on this repo.

[vadikmironov]

Thanks @dzbarsky — very helpful. To track the right target: is the plan to publish aspect_rules_lint_rust (the rules_rs module from #846) and drop aspect_rules_lint_rules_rust altogether or treat it as a transitional stop-gap and publish in parallel both aspect_rules_lint_rust and aspect_rules_lint_rules_rust? Note it currently hits the same #879 blockers (lint/rust export-ignore'd, in-tree local_path_override), so the publish flow will need to cover those too.

Happy to validate any further commits against the repro repo once submitted. Thanks for pushing this forward.

[dzbarsky]

The plan of record I have discussed with @jbedard is to publish aspect_rules_lint_rust and keep aspect_rules_lint_rules_rust unpublished, potentially deleting it. The benefit of not deleting would be to make it easier for consumers to vendor it into their repo if they want to pick up the maintenance burden. Ultimately this is just my understanding, I'm not a maintainer on this repo!

But yes, you're right, we will need the publish workflow to create an archive scoped to just the lint/rust subtree.

[jbedard]

Thanks @vadikmironov, knowing someone is actually using this might be what we need to push us to actually publish it properly 👍

What @dzbarsky said outlines my rough plan:

• publish aspect_rules_lint_rust as a standalone MODULE
• leave the rules_rust specific one in the repo for now, hopefully we see no reason to keep it and delete it soon

In the future more tools might also move to standalone MODULEs, ideally without breaking changes in minor releases like with clippy, but rules_lint depending on rules_rust was simply causing too many issues and we had to drop that.

[scasagrande]

I just stumbled upon this same issue while trying to improve the clippy experience for my developers

[dzbarsky]

You can point an archive_override at my fork's release until we get a real BCR release up https://github.com/dzbarsky/rules_lint/releases/tag/rust-v0.0.0-test

[vadikmironov]

@jbedard , @dzbarsky , the packaging side of this is fixed in 2.7.1 — aspect_rules_lint_rust@0.0.2 is on the BCR and resolves via a plain bazel_dep, no overrides. Thanks a lot! 🎉

I did update a minimal repro (https://github.com/vadikmironov/repro_aspect_rules_lint_issue_879) and there is a catch for repos on rules_rust: the clippy aspect silently no-ops. :rust_app.lint passes green, the report is empty, and -s shows the aspect's action is just touch …report && echo 0 > …exit_code — clippy-driver never runs.

aspect_rules_lint_rust's MODULE.bazel pulls @rules_rust via rules_rs (use_extension("@rules_rs//rs:rules_rust.bzl", …)), so the aspect's rust_clippy_action.get_clippy_ready_crate_info(target, ctx) (clippy.bzl:134) looks for CrateInfo from rules_rs++rules_rust+rules_rust. A consumer's target built by BCR rules_rust@0.70.0 (rules_rust+) carries a different CrateInfo, so crate_info is None and the aspect hits the noop_lint_action branch (clippy.bzl:144).

[dzbarsky]

Ah, that's really unfortunate. The right way to resolve that would be to define these providers in a common modules that rules_rs and rules_rust can both share, but the rules_rust maintainers were not interested in collaborating on that and wanted to make it harder for an alternate ruleset to exist.

Your best options are likely to either vendor the rules_rust variant of the lint rules into your repo (and pick up the maintenance burden, including the custom process wrapper, etc) or to consider migrating to rules_rs!

[jbedard]

@dzbarsky is there any other method of doing this? An extra aspect_rules_lint_rust setup step in a users MODULE if they are only using rules_rust? Or also publish the other rust MODULE?

[vadikmironov]

may I propose at least to fail in case of mismatch? I'll work around for now, but the default behaviour (green on error) is not great. I can propose a tiny change to clippy.bzl along the lines of:

if not crate_info and len(files_to_lint) > 0 and not _has_skip_tag(ctx.rule):
    fail("clippy can't lint {}: no rules_rust CrateInfo, so it is built by a different rules_rust than aspect_rules_lint_rust provides.".format(target.label))

before the noop action if everyone comfortable?

[dzbarsky]

@vadikmironov Perhaps the right safeguard would be to declare required_providers = [CrateInfo] on the aspect?

[vadikmironov]

Thanks @dzbarsky - required_providers = [rust_common.crate_info] does work as a safeguard. I just tried it against the repro repo and while both achieve the same (no false green), they differ in the error message:

• required_providers = [rust_common.crate_info]

  ERROR: apps/rust_app/BUILD:12:12: in clippy_test rule //apps/rust_app:rust_app.lint:
      asserts = [a for src in ctx.attr.srcs for a in _write_assert(ctx, src[OutputGroupInfo].rules_lint_human)]
  Error: 'OutputGroupInfo' value has no field or method 'rules_lint_human'
  ERROR: Analysis of target '//apps/rust_app:rust_app.lint' failed; build aborted

• explicit fail() in the aspect

  ERROR: apps/rust_app/BUILD:6:12: in clippy aspect on rust_binary rule //apps/rust_app:rust_app:
  Error in fail: clippy can't lint //apps/rust_app:rust_app: no rules_rust CrateInfo, so it is built by a different rules_rust than aspect_rules_lint_rust provides.

required_providers looks neat, but the message is harder to parse. It would be beneficial to supplement it with the changes in lint_test.bzl where it fails to do something like:

  asserts = []
  for src in ctx.attr.srcs:
      if OutputGroupInfo not in src or not hasattr(src[OutputGroupInfo], "rules_lint_human"):
          fail(("lint_test '{}': the lint aspect produced no report for '{}' + some sensible description").format(ctx.label, src.label))