Written by AI, reviewed by human to be a real issue.
Description
discover_bazel_rust_project falls back to //... for no-argument/root rust-analyzer discovery. In large mixed Bazel workspaces, that broad target pattern can make rust-analyzer project generation analyze non-Rust targets, incompatible targets, or targets that only fail under the forced rust-analyzer platform/configuration.
This makes root discovery fragile and expensive even when the workspace has a clear smaller set of Rust targets that should be used for rust-analyzer.
Current behavior
When rust-analyzer invokes discovery without a source-file argument, discover_bazel_rust_project resolves the target pattern to //... and passes that to generate_rust_project.
For mixed workspaces this can fail before producing rust-project.json, or produce a much larger project than needed, because Bazel has to analyze targets that are irrelevant to Rust editing.
Expected behavior
There should be a supported way to configure the root discovery target set, for example by passing a Bazel query used only when no source-file argument maps to a more specific package target.
For example, a workspace could configure root discovery to query only Rust targets or only curated top-level Rust targets, while source-file discovery continues to use the existing package-scoped behavior.
Reproduction shape
- Use a Bazel workspace containing Rust targets plus non-Rust or platform-specific targets.
- Configure rust-analyzer to use
discover_bazel_rust_project at the workspace root.
- Trigger root discovery with no source-file argument.
- Observe that discovery analyzes
//..., which can include unrelated or incompatible targets and fail or become very slow.
Impact
This hurts rust-analyzer setup for monorepos and mixed-language Bazel workspaces. Users who only need a Rust-focused target set cannot express that through the discovery tool, so the default //... behavior becomes the limiting factor.
Possible solution
Add a root-discovery-only query option such as:
--root-target-query='kind("rust_.* rule", //...)'When no rust-analyzer source-file argument maps to a package target, run that query and pass the resulting labels to project generation. When rust-analyzer asks about a specific source file, keep the existing package-scoped target discovery.
Written by AI, reviewed by human to be a real issue.
Description
discover_bazel_rust_projectfalls back to//...for no-argument/root rust-analyzer discovery. In large mixed Bazel workspaces, that broad target pattern can make rust-analyzer project generation analyze non-Rust targets, incompatible targets, or targets that only fail under the forced rust-analyzer platform/configuration.This makes root discovery fragile and expensive even when the workspace has a clear smaller set of Rust targets that should be used for rust-analyzer.
Current behavior
When rust-analyzer invokes discovery without a source-file argument,
discover_bazel_rust_projectresolves the target pattern to//...and passes that togenerate_rust_project.For mixed workspaces this can fail before producing
rust-project.json, or produce a much larger project than needed, because Bazel has to analyze targets that are irrelevant to Rust editing.Expected behavior
There should be a supported way to configure the root discovery target set, for example by passing a Bazel query used only when no source-file argument maps to a more specific package target.
For example, a workspace could configure root discovery to query only Rust targets or only curated top-level Rust targets, while source-file discovery continues to use the existing package-scoped behavior.
Reproduction shape
discover_bazel_rust_projectat the workspace root.//..., which can include unrelated or incompatible targets and fail or become very slow.Impact
This hurts rust-analyzer setup for monorepos and mixed-language Bazel workspaces. Users who only need a Rust-focused target set cannot express that through the discovery tool, so the default
//...behavior becomes the limiting factor.Possible solution
Add a root-discovery-only query option such as:
--root-target-query='kind("rust_.* rule", //...)'When no rust-analyzer source-file argument maps to a package target, run that query and pass the resulting labels to project generation. When rust-analyzer asks about a specific source file, keep the existing package-scoped target discovery.