test: include `rename_path_inside_use_tree`.
Keeps tracks the progress of the changes. 3 other tests broke with the changes
of this.
feat: rename all other usages within the current file.
feat: fix most of the implementation problems.
test: `rename_path_inside_use_tree` tests a more complicated scenario.
Previously, the documentation field was the same as the text shown to
users when they hover over that symbol. The documentation should
really just be the doc comment, and as of #16179 the signature is
already stored in the signatureDocumentation field.
Abstract more over ItemTreeLoc-like structs
Allows reducing some code duplication by using functions generic over said structs. The diff isn't negative due to me adding some additional impls for completeness.
feat: enable excluding refs search results in test
## Change
Here I introduce a new `ReferenceCategory::Test` type to indicate whether the function where this reference is located is marked as `#[test]`, and expose an config item (`rust-analyzer.references.excludeTests`) to client.
I also changed the signature of `ReferenceCategory::new`, adding a `sema: &Semantics<'_, RootDatabase>` param to do some hir analysis. Hope the current implementation is good to go.
## Demo
`"rust-analyzer.references.excludeTests": false`
`"rust-analyzer.references.excludeTests": true`
close https://github.com/rust-lang/rust-analyzer/issues/14530
This commit also adds `tracing` to NotificationDispatcher/RequestDispatcher,
bumps `rust-analyzer-salsa` to 0.17.0-pre.6, `always-assert` to 0.2, and
removes the homegrown `hprof` implementation in favor of a vendored
tracing-span-tree.
feat: Support for GOTO def from *inside* files included with include! macro
close#14937
Try to implement goto def from *inside* files included with include! macro.
This implementation has two limitations:
1. Only **one** file which calls include! will be tracked. (I think multiple file be included is a rare case and we may let it go for now)
2. Mapping token from included file to macro call file (semantics.rs:646~658) works fine but I am not sure is this the correct way to implement.
