11369: feat: Add type hint for keyword expression hovers r=Veykril a=danii
Adds the return type of keywords to tool-tips where it makes sense. This applies to: `if`, `else`, `match`, `loop`, `unsafe` and `await`. Thanks to `@Veykril` for sharing the idea of putting return type highlighting on other keywords!
Closes#11359
Co-authored-by: Daniel Conley <himself@danii.dev>
11281: ide: parallel prime caches r=jonas-schievink a=jhgg
cache priming goes brrrr... the successor to #10149
---
this PR implements a parallel cache priming strategy that uses a topological work queue to feed a pool of worker threads the crates to index in parallel.
## todo
- [x] should we keep the old prime caches?
- [x] we should use num_cpus to detect how many cpus to use to prime caches. should we also expose a config for # of worker CPU threads to use?
- [x] something is wonky with cancellation, need to figure it out before this can merge.
Co-authored-by: Jake Heinz <jh@discordapp.com>
11145: feat: add config to use reasonable default expression instead of todo! when filling missing fields r=Veykril a=bnjjj
Use `Default::default()` in struct fields when we ask to fill it instead of putting `todo!()` for every fields
before:
```rust
pub enum Other {
One,
Two,
}
pub struct Test {
text: String,
num: usize,
other: Other,
}
fn t_test() {
let test = Test {<|>};
}
```
after:
```rust
pub enum Other {
One,
Two,
}
pub struct Test {
text: String,
num: usize,
other: Other,
}
fn t_test() {
let test = Test {
text: String::new(),
num: 0,
other: todo!(),
};
}
```
Co-authored-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>
Co-authored-by: Coenen Benjamin <benjamin.coenen@hotmail.com>
11088: closes#10446 hide type inlay hints r=Veykril a=Heinenen
Passes tests as described in #10446
Works for all happy cases, there may be some cases that I forgot as I am not that familiar with Rust and r-a (yet).
Co-authored-by: Heinenen <th.m.heinen@gmail.com>
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>
10563: feat: Make "Generate getter" assist use semantic info r=agluszak a=agluszak
This PR makes "Generate getter" assist use semantic info instead of dealing with types encoded as strings.
Getters for types which are:
- `Copy` no longer return references
- `AsRef<str>` (i.e. `String`) return `&str` (instead of `&String`)
- `AsRef<[T]>` (i.e. `Vec<T>`) return `&[T]` (instead of `&Vec<T>`)
- `AsRef<T>` (i.e. `Box<T>`) return `&T` (instead of `&Box<T>`)
- `Option<T>` return `Option<&T>` (instead of `&Option<T>`)
- `Result<T, E>` return `Result<&T, &E>` (instead of `&Result<T, E>`)
String, Vec, Box and Option were previously handled as special cases.
Closes#10295
Co-authored-by: Andrzej Głuszak <gluszak.andrzej@gmail.com>
10538: fix: matching brace should prefer brace on cursor's right r=Veykril a=codgician
I observed a brace matching issue with the following Rust code:
```rust
let x = (1 + (2 + 3)) * 4;
```
In a situation like `<|>(1 + (2 + 3)) * 4`, the cursor will go to `(1 + (2 + 3)<|>) * 4`, and if user tries to match bracket again it will go like `(1 + <|>(2 + 3)) * 4` while logically the expected result should be `<|>(1 + (2 + 3)) * 4`. This behavior exists in both line cursor style and block cursor style.
This PR fixes this by letting `matching_brace` prefer the brace to cursor's right when the cursor lies between multiple consecutive braces. It **does NOT** fix#1942 but could be related. Please review.
Co-authored-by: codgician <15964984+codgician@users.noreply.github.com>
10423: Internal: refactor for mdbook plugin r=Veykril a=HKalbasi
This PR is for upstreaming changes that I made for mdbook plugin. Changes are adding inlay hints to `StaticIndex` and changing some functions for working around privacy of crates.
Aside this, is it okay if I bring the plugin in tree? It is a simple binary crate. I feel it will better maintained here and become resistant to api changes.
Co-authored-by: hamidreza kalbasi <hamidrezakalbasi@protonmail.com>
This renames `descend_into_macros` to `descend_into_macros_single` and `descend_into_macros_many` into `descend_into_macros`.
However, this does not touch a function in `SemanticsImpl` of same name.
10467: Optimize CodeLens for references/impls r=Veykril a=ericsampson
Don't do unnecessary work.
Followup to #10447 . cc `@Veykril`
Co-authored-by: Eric Sampson <esampson@eaze.com>
