rust-analyzer: Support local imports (use statements in blocks)

Inside a function, I often write something like this:

use Request as R;

match ... {
    R::Info => {...},
    ...
}

But RA seems to have a problem with such imports:

Failed to exactly resolve the symbol. This is probably because rust_analyzer does not yet support traits.
These items were found instead:

Request

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Reactions: 30
  • Comments: 25 (21 by maintainers)

Commits related to this issue

Most upvoted comments

This is now implemented and was fixed by https://github.com/rust-analyzer/rust-analyzer/pull/7614 / https://github.com/rust-analyzer/rust-analyzer/pull/7627.

There are still some known bugs and missing parts, like local impls (which should at least work for types that are also local), and some remaining cleanups to be done, but the bulk of the work is now done, so closing.

This is not planned for the nearest future

At the risk of dragging this on more, I just want to make the point that from the perspective of this particular user, false positive compilation errors would have the most positive impact on my experience using RA – substantially more than refactoring tools, search & replace tools, further performance improvements or more code sharing. Of course this disregards the experience of RA contributors and wider ecosystem benefits from things like code sharing, but I feel like it should count for something.

I don’t know if/how RA prioritizes work currently – making that more transparent might also help in the sense of making it more concrete what trade-offs are affecting issues like this. Also, this is the kind of thing where I wonder if a focused fundraising effort could help – I for one would gladly contribute some cash to help prioritize this, but I don’t think my one-man business can currently sustain paying for the entirety of 1-2 person-weeks of work.

I’d just like to chime in with some motivation on why I think supporting local use statements is an important issue:

Increasingly I only put a use statement at the top of a file if the imported symbol will be used throughout the file. Instead I prefer my use-statements inside my functions. I find that this improves the readability of my code as it makes it more obvious where a certain symbol came from (without the reader having to scroll to the top of the file). But maybe even more importantly it improves refactorability (yes, it is a word). Earlier when moving code between files I needed to spend a lot of time figuring out which use statements (and before that #includes) to copy and/or move to the other file. When the use statements are part of the function body, that work is almost completely gone.

In short: just like I try to limit the scope of my variables, I try to limit the scope of my use statements.

Just avoided creating another duplicate of this… Given the amount of refs and duplicates this looks like top priority.

Also, the main complication here is not actually implementing the logic, but doing it in a way that doesn’t require us to parse all function bodies all the time.

I think this and the related #1559 are the most duplicated issues on this tracker, so it’s clear they are important. On the other hand, they’re not trivial to implement and nobody has put in the effort or the funding for it. They will be implemented, but other foundational work like sharing the parser between the compiler and rust-analyzer is more important.