9418: internal: Include `self` in usage search for modules in their definition source r=Veykril a=Veykril
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9413: internal: Deduplicate ast expression walking logic r=Veykril a=Veykril
Deduplicates the duplication introduced in #9375 and #9396 while also fixing a few bugs in both the assist and related highlighting.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
Macro that deep clone the tokens but otherwise preserves source
locations and hygiene info is an interesting case for IDE support. Lets
have this, although we don't actively use it at the moment.
9380: feat: Implement goto_declaration support r=matklad a=Veykril
This is just a simple implementation that falls back to `goto_definition` for everything but modules where it goes to the actual module declaration if possible.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9353: Include extra targets when the pkg_root is not the same as the target root. r=matklad a=rezural
Fixes#7715
For example, if a sub-crate includes sets the path='../somewhere-else/lib.rs', the files will not be in pkg_root , but in the target root's parent.
It may actually be in root.parent().parent(), I'm not sure about that.
At the moment it is just a fix, are there any relevant tests that this could go in? I've got about 1 brain cell left... but im happy to add tests where appropriate.
Co-authored-by: rezural <rezural@protonmail.com>
9383: internal: Rewrite token tree lowering to use an explicit stack r=jonas-schievink a=jonas-schievink
Part of https://github.com/rust-analyzer/rust-analyzer/issues/9358, this fixes the first cause of the stack overflow there. Unfortunately we now run into a stack overflow in the parser.
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
Definition::visibility was implemented in a rather roundabout way -- by
asking the parent module about the effective visibility.
This is problematic for a couple of reasons:
* first, it doesn't work for local items
* second, asking module about visibility of a child is a linear
operation (that's a problem in itself, tracked in #9378)
Instead, lets ask the declared visibility directly, we have all the code
for it, and need only to actually us it.
