Lazy loading crates in the workspace comes with the limitation that symbol searches may not be exhaustive, since rust-analyzer may be unaware of any reverse dependencies of the current crate. To support people who'd like to guarantee symbol searches are always exhaustive, we should add a --include-reverse-deps flag to discover and check/clippy that also loads all of the reverse dependencies of the current crate (in addition to the dependencies). I'm not quite sure yet how best to support this for check/clippy, but in the worst case scenario, it should be possible to pass specifically the packages we want using -p.
In the case of discover, including reverse dependencies in the graph could end up loading most/all of the crates in the workspace if you're working on a library that is widely depended on in the workspace. That said, I think we might be able to make this better by holding off on loading the dependencies of the reverse dependencies of the current crate. For example, let's say we have a crate B that has no dependencies and a crate A that depends on B in addition to many other crates. If a user opens a file in crate B, we'd like to make rust-analyzer aware of A, since it uses items from B. However, we don't need to load the whole dependency graph of A to support this: it should be enough just to load A itself. Of course, if a user opens a file from A, then we'd want to load all of the dependencies of A. Unfortunately, I'm not sure how possible it is to get this to happen: if we tell rust-analyzer about A but not about any of its dependencies, opening a file from A might not prompt it to invoke cargo-subspace discover again, since it thinks it already knows everything about A. Some more investigation is warranted here...
Lazy loading crates in the workspace comes with the limitation that symbol searches may not be exhaustive, since rust-analyzer may be unaware of any reverse dependencies of the current crate. To support people who'd like to guarantee symbol searches are always exhaustive, we should add a
--include-reverse-depsflag todiscoverandcheck/clippythat also loads all of the reverse dependencies of the current crate (in addition to the dependencies). I'm not quite sure yet how best to support this forcheck/clippy, but in the worst case scenario, it should be possible to pass specifically the packages we want using-p.In the case of
discover, including reverse dependencies in the graph could end up loading most/all of the crates in the workspace if you're working on a library that is widely depended on in the workspace. That said, I think we might be able to make this better by holding off on loading the dependencies of the reverse dependencies of the current crate. For example, let's say we have a crate B that has no dependencies and a crate A that depends on B in addition to many other crates. If a user opens a file in crate B, we'd like to make rust-analyzer aware of A, since it uses items from B. However, we don't need to load the whole dependency graph of A to support this: it should be enough just to load A itself. Of course, if a user opens a file from A, then we'd want to load all of the dependencies of A. Unfortunately, I'm not sure how possible it is to get this to happen: if we tell rust-analyzer about A but not about any of its dependencies, opening a file from A might not prompt it to invokecargo-subspace discoveragain, since it thinks it already knows everything about A. Some more investigation is warranted here...