Florian Diebold
Florian Diebold
> If there are two projects, A and B, and A uses B, then opening B first and invoking find useages won't find usages in A, because we don't know...
The problem with changing the configs currently is that it depends on the client, unless we finally introduce `rust-analyzer.toml` :grimacing:
See #8631, we might want to lazily load non-toplevel Cargo projects in any case...
This is also related to #6388, I think -- if we're able to load Cargo projects when you open a file from them, the next step would be to create...
Btw, we also have the "changing configs" use case for cargo features (toggling them on/off)...
@bugadani you need to configure linkedProjects like ```json { "rust-analyzer.linkedProjects": ["components/rustlib/Cargo.toml"] } ``` , not with an inline rust-project.json.
This should be called `One` like in [rustfmt](https://rust-lang.github.io/rustfmt/?version=v1.4.38&search=import#imports_granularity).
I think that would be far too cluttered. The outline is supposed to be an outline, not a complete syntax tree.
So, what would that concretely mean compared to the current API? I think 1. some types that currently are just data would gain an identity / location in the tree...
Would there be a `HirNode` analogous to `SyntaxNode`, so you can do `some_expression_hir.ancestors().find_map(hir::Function::cast)`? I wonder whether the HIR needs that flexibility, or whether there could instead be something like `some_expression_hir.ancestor::()`.