2768: Rename VS Code extension to rust-analyzer r=matklad a=matklad
I want to merge this before release on Monday, such that we can give heads up on twitter
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
2788: Fix file_structure() to recognize macro_rules! r=flodiebold a=ruabmbua
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/2774.
Not sure what to do about classifying macro definitions. Maybe make all macro invocations a function invocation?
Co-authored-by: Roland Ruckerbauer <roland.rucky@gmail.com>
2814: Update crates r=matklad a=kjeremy
Adds a new dependency on autocfg 1.0. There are pending PRs against indexmap, crossbeam and rand to bring them up.
Co-authored-by: Jeremy Kolb <kjeremy@gmail.com>
2807: Use attr location for builtin derive in goto-implementation r=matklad a=edwin0cheng
This PR is use attribute location for builtin derive in `ImplBlock`'s NavigationTarget such that the goto-implementation will goto to a correct position.
Related to #2531
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
2803: Fix various names, e.g. Iterator not resolving in core prelude r=matklad a=flodiebold
Basically, `Iterator` is re-exported via several steps, which happened to not be
resolved yet when we got to the prelude import, but since the name resolved to
the reexport from `core::iter` (just to no actual items), we gave up trying to
resolve it further.
Maybe part of the problem is that we can have
`PartialResolvedImport::Unresolved` or `PartialResolvedImport::Indeterminate`
with `None` in all namespaces, and handle them differently.
Fixes#2683.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
2727: Qualify paths in 'add impl members' r=flodiebold a=flodiebold
This makes the 'add impl members' assist qualify paths, so that they should resolve to the same thing as in the definition. To do that, it adds an algorithm that finds a path to refer to any item from any module (if possible), which is actually probably the more important part of this PR 😄 It handles visibility, reexports, renamed crates, prelude etc.; I think the only thing that's missing is support for local items. I'm not sure about the performance, since it takes into account every location where the target item has been `pub use`d, and then recursively goes up the module tree; there's probably potential for optimization by memoizing more, but I think the general shape of the algorithm is necessary to handle every case in Rust's module system.
~The 'find path' part is actually pretty complete, I think; I'm still working on the assist (hence the failing tests).~
Fixes#1943.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
Co-authored-by: Florian Diebold <florian.diebold@freiheit.com>
Basically, `Iterator` is re-exported via several steps, which happened to not be
resolved yet when we got to the prelude import, but since the name resolved to
the reexport from `core::iter` (just to no actual items), we gave up trying to
resolve it further.
Maybe part of the problem is that we can have
`PartialResolvedImport::Unresolved` or `PartialResolvedImport::Indeterminate`
with `None` in all namespaces, and handle them differently.
Fixes#2683.
