11000: fix: insert whitespaces into assoc items for assist when macro generated r=Veykril a=Veykril
This is obviously only a temporary hack which still produces ugly looking items, but as long as the syntax is valid one can at least have rustfmt fix the formatting again.
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/6588
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
10965: minor: Remove dead assists-related function r=Veykril a=lnicola
Unless I'm missing something, `assists_with_fixes` seems to be always used and ends up in the same code path.
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
10978: internal: Only prime direct dependencies of the workspace crates r=jonas-schievink a=lnicola
This reduces the number of primed crates on `self` from 177 to 105.
```text
# baseline
86521 me 20 0 2939M 562M 14320 S 0.0 0.9 0:07.10 37 rust-analyzer
# pr
99947 me 20 0 2935M 549M 14424 S 0.0 0.9 0:07.10 37 rust-analyzer
```
The RAM usage seems to vary a lot, so I'm not sure the improvement shown above is real.
We also drop the topological sorting, although it might still make sense to do the dependencies before the workspace crates. But since it's only used to make the progress reporting a bit more fine, it probably doesn't matter too much.
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
10958: internal: add "Shuffle Crate Graph" command r=jonas-schievink a=jonas-schievink
May be useful for debugging issues like https://github.com/rust-analyzer/rust-analyzer/issues/10084
bors r+
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
10891: fix: emit trait names in moniker identifier r=Veykril a=tjdevries
Hi,
Not sure if this is the best fix for the problem, but I noticed that functions that part of a trait are not namespaced with the trait name, so this could lead to problems if you had a function and a trait-function both defined in the same module.
Thanks!
TJ
Co-authored-by: TJ DeVries <devries.timothyj@gmail.com>
10872: ide_db: build symbol index from crate def map r=Veykril a=jhgg
fixes#4842, #10764
Is this looking correct? 👀
- [x] build the symbol index based upon the CrateDefMap for the given crate in `crate_symbols`
- [x] make it multi threaded again, and figure out how to cache each moduleid's symbol index in salsa.
- [x] NavigationTarget for names in macros is wrong, need to figure out how to compute a text range in the original file id?
- [x] cleanup some duped code
- [x] collect macros from `ItemScope.declared_macros()` into symbol index.
- [x] store declared macros in `ItemScope` so we can figure out where macros were defined for the index.
- [x] do something about `SymbolIndex::for_files` - ideally it should use the new module symbol index stuff.
- [x] delete `source_file_to_file_symbols` & co...
- [x] figure out what to do about `library_symbols`
- [x] maybe... speed up the new `library_symbols` - the new impl is probably much slower, and definitely much less parallel. **deciding to do nothing here, we can optimize later if necerssary.**
- [x] fix failing test: `navigation_target::tests::test_nav_for_symbol` - notably the crate def map doesn't seem to find declarations inside function.
- [x] now a bunch of other tests are failing around auto_import & qualify_path handlers. :(
- [x] need to assoc items in traits and impls
Co-authored-by: Jake Heinz <jh@discordapp.com>
10798: ide: show go to for function hover return type r=Veykril a=jhgg
I've found myself wanting this... adds to the hover quick go-to for a function's return type:
This is particularly useful when you are hovering over a function in a long chain, like:
```rust
foo.bar().b$0az().some_trait_fn();
```
where `baz`'s return type is not immediately obvious, but the chain is not long enough to trigger chain inlay hints...
i guess I could just select `foo.bar().baz()` too to get the types too...
Co-authored-by: Jake Heinz <jh@discordapp.com>
10785: ide: show const value in hover r=jhgg a=jhgg
fixes#10783
I think my original attempt was incorrect, because it looks like `HirDisplay` is used in more places than just the hover.
So, I've attempted it again in 312eafe, this time specifically just rendering the value in `hover::render`
pictoral:
Co-authored-by: Jake Heinz <jh@discordapp.com>
Co-authored-by: Jake <jh@discordapp.com>
