Rust LSP

[casualjim]

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

[DeusData]

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]

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]

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