6 ms·

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 im

by rtpg 25d ago

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 any typo for example Inversely... do you have a ballpark for what the size of the on-disk structures end up being? Not that it matters _that_ much but Rust projects already have a tendancy to be disk hogs during development

popzxc 25d ago
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 _reachable_ items in _direct_ dependencies; typically project has much less direct dependencies than transitive ones (e.g. 20 direct dependencies can fan out to 1000 transitive deps), and each dependency usually has less exported items than total amount of items. Finally, for that you only need semantic data (e.g. items) rather than bodies. So while it's a big task (though finding references is still significantly bigger and tougher, because that's where it gets to "it can be anywhere in reverse dependencies bodies), it's not "we need the whole world". As for the size -- the Rust Glancer artifacts for Rust Glancer itself currently take 225mb. And that's proportial to the project size only, e.g. it doesn't grow over time on its own.
- afdbcreid 22d ago
  Unfortunately that does not work. Consider: // Crate indirect_dep: pub struct Foo; // Crate direct_dep: extern crate indirect_dep; pub use indirect_dep::*; // Crate my_crate: use direct_dep::$0; ($0 denotes the cursor). You cannot know what to complete without analyzing `indirect_dep`. Add macros to the mix and you're going to get a nightmare (yes, name resolution in Rust is a nightmare). In fact, you sometimes need to do type inference inside bodies to infer other bodies, because auto traits propagate across opaques. You might say this does not matter because it only matters for diagnostics... But it does not. It can matter for method resolution. In general, I'm fairly sure that it is just impossible to build a 100% correct analyzer for Rust code without a query system like rustc's (it can be stored on disk, that's a different story). You can go pretty far without - and this will be enough for some people for an IDE! - but not all the way.

by rtpg 25d ago

popzxc 25d ago

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 _reachable_ items in _direct_ dependencies; typically project has much less direct dependencies than transitive ones (e.g. 20 direct dependencies can fan out to 1000 transitive deps), and each dependency usually has less exported items than total amount of items. Finally, for that you only need semantic data (e.g. items) rather than bodies. So while it's a big task (though finding references is still significantly bigger and tougher, because that's where it gets to "it can be anywhere in reverse dependencies bodies), it's not "we need the whole world". As for the size -- the Rust Glancer artifacts for Rust Glancer itself currently take 225mb. And that's proportial to the project size only, e.g. it doesn't grow over time on its own.

afdbcreid 22d ago
Unfortunately that does not work. Consider: // Crate indirect_dep: pub struct Foo; // Crate direct_dep: extern crate indirect_dep; pub use indirect_dep::*; // Crate my_crate: use direct_dep::$0; ($0 denotes the cursor). You cannot know what to complete without analyzing `indirect_dep`. Add macros to the mix and you're going to get a nightmare (yes, name resolution in Rust is a nightmare). In fact, you sometimes need to do type inference inside bodies to infer other bodies, because auto traits propagate across opaques. You might say this does not matter because it only matters for diagnostics... But it does not. It can matter for method resolution. In general, I'm fairly sure that it is just impossible to build a 100% correct analyzer for Rust code without a query system like rustc's (it can be stored on disk, that's a different story). You can go pretty far without - and this will be enough for some people for an IDE! - but not all the way.