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>
11424: Pass required features to cargo when using run action r=Veykril a=WaffleLapkin
When using `F1`->`Rust Analyzer: Run` action on an `example`, pass its `required-features` to `cargo run`. This allows to run examples that were otherwise impossible to run with RA.
Co-authored-by: Maybe Waffle <waffle.lapkin@gmail.com>
When using `F1`->`Rust Analyzer: Run` action on an `example`, pass its
`required-features` to `cargo run`. This allows to run examples that
were otherwise impossible to run with RA.
11182: fix: don't panic on seeing an unexpected offset r=Veykril a=dimbleby
Intended as a fix, or at least a sticking plaster, for #11081.
I have arranged that [offset()](1ba9a924d7/crates/ide_db/src/line_index.rs (L105-L107)) returns `Option<TextSize>` instead of going out of bounds; other changes are the result of following the compiler after doing this.
Perhaps there's still an issue here - I suppose the server and client have gotten out of sync and that probably shouldn't happen in the first place? I see that https://github.com/rust-analyzer/rust-analyzer/issues/10138#issuecomment-913727554 suggests what sounds like a more substantial fix which I think might be aimed in this direction. So perhaps that one should be left open to cover such things?
Meanwhile, I hope that not-crashing is a good improvement: and I can confirm that it works out just fine in the repro I have at #11081.
Co-authored-by: David Hotham <david.hotham@metaswitch.com>
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>
The direct reason for this is to fix CI on windows, which seems to fail
for some reason after we fixed the watcher-selection logic which (I
think) changed the tests behavior to use notify rather than client.
But this patch seems to make sense in general -- file watching is
notoriously finicky, so controlling it explicitly leads to less fragile
tests.
10902: Handle multiple cargo check quick fix spans r=Veykril a=brandondong
Resolves https://github.com/rust-analyzer/rust-analyzer/issues/10705.
**Cause:**
- For a cargo check diagnostic with multiple spans, only a single quick fix action would be created at the location of `spans[0]`. Additionally, the hover window details would only show the location of `spans[0]` next to the message.
**Fix:**
- Allow cargo check quick fix actions to be triggerable from multiple selection ranges. Specifically, if the selection intersects with any of the replacement spans, the quick fix action is shown.
- No change in behavior for the hover window details. It's pretty minor and I think showing multiple locations next to the message may be more confusing anyways.
Co-authored-by: Brandon <brandondong604@hotmail.com>
