Repository navigation
Rust LSP #405
Description
Just opening for discussion, PR is incoming
Rust seems to need a different implementation strategy than the current clean-room resolvers. For many languages, codebase-memory can reconstruct enough type and import semantics from tree-sitter plus per-language registries. For Rust, that approach is likely to fail on the cases users care about most: macro_rules!, derive/proc macros, build-script generated code, cfg/features, trait dispatch, associated functions, generics, and cross-crate workspace resolution. To avoid false graph edges, I think we should lean on rust-analyzer semantics directly rather than trying to reimplement that machinery in C.
The proposed shape is a small, vendorable Rust library built on pinned ra_ap_* rust-analyzer crates, exposing a stable generic C ABI. The C indexer would continue owning the graph pipeline and mapping, while the Rust library would load a Cargo workspace once, resolve call targets in batches, and return source/target file/range evidence with confidence and provenance. External/std/core/unresolved/ambiguous targets would produce diagnostics or no edge, not guessed edges. Proc macros and build scripts would be explicit configuration choices, because they are necessary for accuracy in real Rust projects but have security/performance implications.
I have a prototype along these lines already: generic RustAnalyzer* ABI, generated C header, prefix install/pkg-config smoke test, RA-backed fixture coverage for direct/method/trait/generic/macro-related calls, and conservative no-edge handling for unsafe/generated ambiguity. The intent is to contribute this as an integration path rather than force Rust-specific internals into codebase-memory: CBM adapts its existing file/call/definition records into the ABI, receives resolved call evidence back, and inserts graph edges only when the returned target maps to a stable local/workspace definition.
To that end I created this: https://github.com/casualjim/cbm-rust-analyzer
Activity
DeusData commentedon Jun 1, 2026
Hey @casualjim, thanks for sharing your idea and project. In general I agree with you. The whole idea of "Hybrid LSP" is to basically catch the weak spots of the tree-sitter method. In general I prefer having everything bundled together in my own setup using the architecture provided. An Rust Hybrid LSP is already on the way, just needs some polishing. It is a question of weeks (like sub 2) than months. In general the "integration" path is interesting, but not sure if the project is mature enough for this route. I will post here again once the Rust Hybrid LSP lands. Maybe you can then test it out and give some feedback how it works for you
casualjim commentedon Jun 1, 2026
oic, sure I can test it. I'm curious how you did it
I just kept my thing as a separate repo to get feedback before I worked out how to vendor it. It's already tested on macro heavy projects like clap etc.
DeusData commentedon Jun 11, 2026
Hey @casualjim, 0.8.0 is out with the Rust LSP Hybrid. Can you maybe check it out for completeness? Would be great to get your feedback
github-actions commentedon Aug 20, 2026
Thanks for the report! To move this forward we need a bit more so we can reproduce it ourselves:
codebase-memory-mcp --versionyou're onOnce that's here we'll pick it straight back up. Heads-up: issues left
awaiting-reporterare automatically closed after a few weeks of silence, but a comment reopens the door anytime.github-actions commentedon Sep 11, 2026
This issue has been waiting on more information for 21 days (a version, exact steps, or a public repro), so it's now marked
stale. It will not be closed automatically — a maintainer reviews stale issues by hand. Adding a comment with the details clears the label and puts it straight back in the queue. We're happy to pick it back up the moment we can reproduce it.DeusData commentedon Oct 25, 2026
Thank you for the Rust integration proposal and the offer to test. If you have since compared the bundled implementation against your macro/workspace cases, a short account of the remaining gaps would be useful. The separate rust-analyzer integration direction still needs a maintainer decision.
casualjim commentedon Nov 2, 2026
I have long ago stopped using my own work around and I'm relying on your implementation directly. But I never let you know. For me this is good. lgtm