Florian Diebold
Florian Diebold
I think I would go with option 2 for now, like with the current HIR. I think the store can and maybe has to contain a reference to the DB...
Yeah. On the other hand, you don't usually need the DB to manipulate syntax trees, but you will need it to do things with the HIR. And I don't think...
Yeah. Of the remaining ones, option 1 is more inconvenient than 2, but it makes the connection of the nodes to the store clearer, and maybe that's a good thing...
Not sure, since we won't keep many of these around usually, I think?
Yes, in general the problem here is passing through diagnostics from the collection step for these things. It's not really complicated, but it needs some plumbing.
Just as a note, the fact that this is marked unactionable doesn't mean we don't want to fix it, or that no-one is allowed to work on it. It just...
> It's not as if the rust-analyzer from a few weeks ago was unusable, nor even a few months ago. That's true, but it's also not much more stable or...
I wonder, it might be nice to automatically complete `Default::default()` etc. for traits like this? I.e. have a completion for the full method call?
Or maybe we should just complete `Default::$0` instead of `Default` -- that would apply to all traits in this position :thinking: But for traits with just one member just providing...
We consider Cargo.toml support generally [in scope](https://github.com/rust-lang/rust-analyzer/issues/3565) for rust-analyzer, but so far no one has worked on it. (I think there are many opportunities for interactions between the Cargo.toml-editing features...