With a rust workspace, ALE starts rust-analyzer at the crate root instead of workspace root
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 62/100
Research direction
Start at the named entry point ale_linters#rust#analyzer#GetProjectRoot and reproduce the behavior with a Cargo workspace containing multiple crates. Review the attached analyzer.patch and trace how rust-analyzer is launched for each crate. Done means workspace files use one workspace-root analyzer instance without introducing the ghost characters reported with system.
Written by the indexing model from the issue text.
Description
Information
VIM version
VIM - Vi IMproved 9.2 (2026 Feb 14, compiled Apr 07 2026 19:00:59)
Included patches: 1-316
Operating System: Linux x1 6.19.11-arch1-1 #1 SMP PREEMPT_DYNAMIC Thu, 02 Apr 2026 23:33:01 +0000 x86_64 GNU/Linux
What went wrong
Rust analyzer's ale_linters#rust#analyzer#GetProjectRoot find the project root by finding the nearest Cargo.toml files. When working with a cargo workspace, there are multiple Cargo.toml files. Current code starts a different instance of rust-analyzer for each crate in the workspace- but rust-anaylzer is aware of cargo workspaces, and can be started at the workspace root and shared among all crates in it, which improves cache utilization and reduces memory consumption, since dependencies of multiple crates in the workspace are analyzer once instead of per crate (this includes the workspace crates themselves which usually depend on each other).
Reproducing the bug
- Create a cargo workspace with multiple crates
- edit rust files under each of those crates
- multiple instances of rust-analyzer will be running
I've attached a patch which fixes the bug- however the patch uses system, which at least on my machine causes ghost characters to sometimes appear (I assume due to some sort of bad behavior of running system in the background while the user is typing, though honestly I'm not sure).
- Dominant language
- Vim Script
- Stars
- 14k
- Forks
- 1.5k
- PR merge metrics
- No merged PRs in 30d
Getting set up
- Ships a Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from dense-analysis/ale
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
dense-analysis/ale#5181 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
dense-analysis/ale#5180 · 1 comment ·
-
new tool
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
dense-analysis/ale#5176 ·
-
bug
Difficulty 1/5 Under an hour Newbie friendliness 75/100
dense-analysis/ale#5174 ·
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
dense-analysis/ale#5158 ·
All issues in dense-analysis/ale
Similar issues
-
bug parity
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
WenyuChiou/agent-board#1489 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 72/100
ScoopInstaller/Extras#19364 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
osrep/Runes2P.jl#279 ·
Maintainers usually reply within 1 day
-
Incorrect Ruff version demandedPossibly taken @FrancescoPezzella claimed this today. Open
Difficulty 1/5 Under an hour Newbie friendliness 88/100
zarr-developers/VirtualiZarr#1160 ·
Maintainers usually reply within 3 days
-
area: sdk bug complexity: trivial
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
accensa/x402-facilitator-stellar#697 ·
Maintainers usually reply within 1 day