Rust Glancer: Rust LSP using 100x less RAM

Post by rdescartes » Sun, Aug 23, 2026, 4:53 PM UTC

popzxc wrote: post #114

rdescartes wrote: post #87

Earlier quoted context omitted.

Could you mind to tell me what is your plan on proc-macros ? You said you have an idea to “will not require actual code execution”. On the other hand, RA current method of handling in Proc-Macros are very fragile.

The exact shape is TBD (I target proc macros support for 0.3.0, whereas 0.2.0 will be about completeness/editors support), but in short -- I'm thinking about "plugin"/DSL architecture where proc macro _effects_ can be described beforehand and applied by the LSP without actual code execution. Executing proc macros is a lot of effort, but LSP mostly cares about the externally observable effects, which is a much smaller…

Post by 0x457 » Sun, Aug 23, 2026, 9:16 PM UTC

yk_42 wrote: post #28

0x457 wrote: post #20

Earlier quoted context omitted.

Very little quality, let alone high-quality, code is written in VSCode.

This is an astonishing assertion. Can you back that up with evidence?

Post by yencabulator » Sun, Aug 23, 2026, 10:11 PM UTC

peterfirefly wrote: post #51

> It can use very little memory (target We live in a strange world.

Post by afdbcreid » Tue, Aug 25, 2026, 10:31 PM UTC

popzxc wrote: post #113

rtpg wrote: post #111

Earlier quoted context omitted.

Let's say I type "SomeStructure" and haven't imported it, how does rust glancer _not_ end up poking at all the dependencies to figure out where it is, and to import it? In some sense I feel like that example is the canonical "you need a full picture of the world" case, to the point that it's probably worth special casing _just_ that, and using local analysis for everything... but it seems hard to avoid that pain on a…

On the first question -- auto imports is an example of a "heavy" functionality since we indeed need to scan more than is imported in the project, which is why I'm still working on this to optimize properly (it's decently fast, but I want it to be faster before I'll enable it, since it's also something we want to see in completions, and completions must be _very_ fast). Still, we don't need "everything": we only need…

    // Crate indirect_dep:
    pub struct Foo;
    
    // Crate direct_dep:
    extern crate indirect_dep;
    pub use indirect_dep::*;
    
    // Crate my_crate:
    use direct_dep::$0;

Post by afdbcreid » Tue, Aug 25, 2026, 10:37 PM UTC

popzxc wrote: post #39

t_mahmood wrote: post #36

Earlier quoted context omitted.

But RA already eats up huge amount if storage when working in a large project, if you're using disk cache, it'll gobble up more, That's the biggest complain I had with RA. Somehow never had this issue with jetbrains rust plugin.

I’m not sure if RA intentionally uses storage space itself. It can use storage when running build scripts/expanding proc macros, or when running flycheck diagnostics. In both cases, it’s because it runs cargo and it writes artifacts to the target dir. And if features do not align between “common” cargo commands and configuration rust analyzer has, it can lead to conflicts and even more increased storage size (because…