11791: fix: some fixes and improvements to signature help r=jonas-schievink a=jonas-schievink
bors r+
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
11774: feat: Tag macro calls as unsafe if they expand to unsafe expressions r=Veykril a=Veykril
as long as they aren't inside an unsafe block inside the macro that is.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
11663: Internal: Add hir_def::MacroId, add Macro{Id} to ModuleDef{Id} r=Veykril a=Veykril
With this we can now handle macros like we handle ModuleDefs making them work more like other definitions and allowing us to remove a bunch of special cases. This also enables us to track the modules these macros are defined in, instead of only recording the crate they come from.
Introduces a new class of `MacroId`s (for each of the 3 macro kinds) into `hir_def`. We can't reuse `MacroDefId` as that is defined in `hir_expand` which doesn't know of modules, so now we have two different macro ids, this unfortunately requires some back and forth mapping between the two via database accesses which I hope won't be too expensive.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
11445: Upstream inlay hints r=lnicola a=lnicola
Closes https://github.com/rust-analyzer/rust-analyzer/issues/2797
Closes https://github.com/rust-analyzer/rust-analyzer/issues/3394 (since now resolve the hints for the range given only, not for the whole document. We don't actually resolve anything due to [hard requirement](https://github.com/rust-analyzer/rust-analyzer/pull/11445#issuecomment-1035227434) on label being immutable. Any further heavy actions could go to the `resolve` method that's now available via the official Code API for hints)
Based on `@SomeoneToIgnore's` branch, with a couple of updates:
- I squashed, more or less successfully, the commits on that branch
- downloading the `.d.ts` no longer works, but you can get it manually from https://raw.githubusercontent.com/microsoft/vscode/release/1.64/src/vscode-dts/vscode.proposed.inlayHints.d.ts
- you might need to pass `--enable-proposed-api matklad.rust-analyzer`
- if I'm reading the definition right, `InlayHintKind` needs to be serialized as a number, not string
- this doesn't work anyway -- the client-side gets the hints, but they don't display
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
11595: fix: lower string literals with actual value instead of default r=lnicola a=tysg
Fixes#11582. Some questions below in the code review section.
Co-authored-by: Tianyi Song <42670338+tysg@users.noreply.github.com>
11490: Correctly fix formatting doc tests with generics r=Veykril a=KarlWithK
Before the doc_test would be outputted like this:
```zsh
"Foo<T, U>::t"
```
However, this would cause problems with shell redirection. I've changed it
so when generics are involved we simply wrap the expression under quotes as so:
```zsh
"\"Foo<T, U>::t\""
```
Note:
At the cost of adding this, I had to allocate a new string via
`format!{}`. However, I argue this is alright as this for just for
outputting the name of the doc test.
The following tests have been changed:
```
runnables::tests::doc_test_type_params
runnables::tests::test_doc_runnables_impl_mod
runnables::tests::test_runnables_doc_test_in_impl
```
Closes https://github.com/rust-analyzer/rust-analyzer/issues/11489
Co-authored-by: KarlWithK <jocelinc60@outlook.com>
Co-authored-by: SeniorMars <jocelinc60@outlook.com>
11481: Display parameter names when hovering over a function pointer r=Veykril a=Vannevelj
Implements #11474
The idea is pretty straightforward: previously we constructed the hover based on just the parameter types, now we pass in the parameter names as well. I went for a quick-hit approach here but I expect someone will be able to point me to a better way of resolving the identifier.
I haven't figured out yet how to actually run my rust-analyzer locally so I can see it in action but the unit test indicates it should work.
Co-authored-by: Jeroen Vannevel <jer_vannevel@outlook.com>
Before the doc_test would be outputted like this:
"Foo<T, U>::t"
However, this would cause shells with shell redirection. I've changed it
so when generics are involved we simply wrap the expression under escape
chanters as so:
"\"Foo<T, U>::t\""
Note:
At the cost of adding this, I had to allocate a new string via
format!{}. However, I argue this is alright as this for just for
outputting the name of the doc test.
The following tests have been changed:
runnables::tests::doc_test_type_params
runnables::tests::test_doc_runnables_impl_mod
runnables::tests::test_runnables_doc_test_in_impl
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>
