Or macro_rules hygiene, or mixed site hygiene. In other words, hygiene for variables and labels but not items.
The realization that made me implement this was that while "full" hygiene (aka. def site hygiene) is really hard for us to implement, and will likely involve intrusive changes and performance losses, since every `Name` will have to carry hygiene, mixed site hygiene is very local: it applies only to bodies, and we very well can save it in a side map with minor losses.
This fixes one diagnostic in r-a that was about `izip!()` using hygiene (yay!) but it introduces a huge number of others, because of #18262. Up until now this issue wasn't a major problem because it only affected few cases, but with hygiene identifiers referred by macros like that are not resolved at all. The next commit will fix that.
feat: render docs from aliased type when type has no docs
Trying to close#18344
- [x] ~Find the docs by traversing upwards if the type itself has none but aliasing for another type that might have.~
- [x] Show docs from aliased type.
- [x] Showing description that we are displaying documentation for different definition in hover box.
feat: respect references.exclude_tests in call-hierarchy
close#18212
### Changes
1. feat: respect `references.exclude_tests` in call-hierarchy
2. Modified the description of `references.exclude_tests`
internal: Don't resolve extern crates in import fix point resolution
The fix point loop won't progress them given the potential extern crate candidates are set up at build time.
feat: Highlight exit points of async blocks
Async blocks act similar to async functions in that the await keywords are related, but also act like functions where the exit points are related.
Fixes#18147
fix: Fix resolution of label inside macro
When working on Something Else (TM) (I left a hint in the commits :P), I noticed to my surprise that labels inside macros are not resolved. This led to a discovery of *two* unrelated bugs, which are hereby fixed in two commits.
This fixes a bug where labels inside macros were not resolved, but more importantly this prepares us to a future where we have hygiene, and textual equivalence isn't enough to resolve identifiers.
internal: Send less data during `textDocument/completion` if possible
Similar to https://github.com/rust-lang/rust-analyzer/pull/15522, stops sending extra data during `textDocument/completion` if that data was set in the client completions resolve capabilities, and sends those only during `completionItem/resolve` requests.
Currently, rust-analyzer sends back all fields (including potentially huge docs) for every completion item which might get large.
Same as the other one, this PR aims to keep the changes minimal and does not remove extra computations for such fields — instead, it just filters them out before sending to the client.
The PR omits primitive, boolean and integer, types such as `deprecated`, `preselect`, `insertTextFormat`, `insertTextMode`, etc. AND `additionalTextEdits` — this one looks very dangerous to compute for each completion item (as the spec says we ought to if there's no corresponding resolve capabilities provided) due to the diff computations and the fact that this code had been in the resolution for some time.
It would be good to resolve this lazily too, please let me know if it's ok to do.
When tested with Zed which only defines `documentation` and `additionalTextEdits` in its client completion resolve capabilities, rust-analyzer starts to send almost 3 times less characters:
Request:
```json
{"jsonrpc":"2.0","id":104,"method":"textDocument/completion","params":{"textDocument":{"uri":"file:///Users/someonetoignore/work/rust-analyzer/crates/ide/src/inlay_hints.rs"},"position":{"line":90,"character":14},"context":{"triggerKind":1}}}
```
<img width="1338" alt="image" src="https://github.com/user-attachments/assets/104f19b5-7095-4fc1-b008-5d829623b2e2">
Before: 381944 characters
[before.json](https://github.com/user-attachments/files/17092385/before.json)
After: 140503 characters
[after.json](https://github.com/user-attachments/files/17092386/after.json)
After Zed's [patch](https://github.com/zed-industries/zed/pull/18212) to enable all resolving possible: 84452 characters
[after-after.json](https://github.com/user-attachments/files/17092755/after-after.json)
fix: Fix a bug in span map merge, and add explanations of how span maps are stored
Because it took me hours to figure out that contrary to common sense, the offset stored is the *end* of the node, and we search by the *start*. Which is why we need a convoluted `partition_point()` instead of a simple `binary_search()`. And this was not documented at all. Which made me make mistakes with my implementation of `SpanMap::merge()`.
The other bug fixed about span map merging is correctly keeping track of the current offset in presence of multiple sibling macro invocations. Unrelated, but because of the previous issue it took me hours to debug, so I figured out I'll put them together for posterity.
Fixes#18163.
fix: Fix name resolution when an import is resolved to some namespace and then later in the algorithm another namespace is added
The import is flagged as "indeterminate", and previously it was re-resolved, but only at the end of name resolution, when it's already too late for anything that depends on it.
This issue was tried to fix in https://github.com/rust-lang/rust-analyzer/pull/2466, but it was not fixed fully.
That PR is also why IDE features did work: the import at the end was resolved correctly, so IDE features that re-resolved the macro path resolved it correctly.
I was concerned about the performance of this, but this doesn't seem to regress `analysis-stats .`, so I guess it's fine to land this. I have no idea about the incremental perf however and I don't know how to measure that, although when typing in `zbus` (including creating a new function, which should recompute the def map) completion was fast enough.
I didn't check what rustc does, so maybe it does something more performant, like keeping track of only possibly problematic imports.
Fixes#18138.
Probably fixes#17630.
Because it took me hours to figure out that contrary to common sense, the offset stored is the *end* of the node, and we search by the *start*. Which is why we need a convoluted `partition_point()` instead of a simple `binary_search()`. And this was not documented at all. Which made me make mistakes with my implementation of `SpanMap::merge()`.
The other bug fixed about span map merging is correctly keeping track of the current offset in presence of multiple sibling macro invocations. Unrelated, but because of the previous issue it took me hours to debug, so I figured out I'll put them together for posterity.
The import is flagged as "indeterminate", and previously it was re-resolved, but only at the end of name resolution, when it's already too late for anything that depends on it.
This issue was tried to fix in https://github.com/rust-lang/rust-analyzer/pull/2466, but it was not fixed fully.
fix: Get rid of `$crate` in expansions shown to the user
Be it "Expand Macro Recursively", "Inline macro" or few other things.
We replace it with the crate name, as should've always been.
Probably fixes some issues, but I don't know what they are.
Previously some expansions were not cached, but were cached in the expansion cache, which caused panics when later queries tried to lookup the node from the expansion cache.
feat: render patterns in params for hovering
Fix#17858
This PR introduces an option to [hir-def/src/body/pretty.rs](08c7bbc2db/crates/hir-def/src/body/pretty.rs) to render the result as a single line, which is then reused for rendering patterns in parameters for hovering.
