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>
10649: internal: Remove `CompletionKind` in favor of `CompletionItemKind` r=Veykril a=Veykril
and move some more tests around
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
10503: Only include targets of packages that are workspace members r=Veykril a=bcully
CargoWorkspace's package list includes packages that are path
dependencies, even if those packages aren't actually members of the
cargo workspace. As a result, rust-analyzer's runnable finder, which
returns the target from the first workspace that has a matching package,
may select the wrong working directory, causing runnables to fail, e.g.,
```
error: package `root` cannot be tested because it requires dev-dependencies and is not a member of the workspace
```
To fix this, we filter out packages that aren't members of the workspace
when searching for targets.
Fixes#7764
Co-authored-by: Brendan Cully <brendan@cully.org>
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>
CargoWorkspace's package list includes packages that are path
dependencies, even if those packages aren't actually members of the
cargo workspace. As a result, rust-analyzer's runnable finder, which
returns the target from the first workspace that has a matching package,
may select the wrong working directory, causing runnables to fail, e.g.,
```
error: package `root` cannot be tested because it requires dev-dependencies and is not a member of the workspace
```
To fix this, we filter out packages that aren't members of the workspace
when searching for targets.
Fixes#7764
10522: fix: make signature info response conform to spec r=lnicola a=muscar
This addreses https://github.com/rust-analyzer/rust-analyzer/issues/10464.
This patch picks up `lsp-types` 0.90.1, which serialises the `SignatureInformation` and `ParameterInformation` with the right casing. It also adds `activeSignature` field as part of the top-level signature response. It keeps `activeParameter` at the top-level for backwards compatibility.
Co-authored-by: Alex Muscar <alex@muscar.eu>
This addreses
https://github.com/rust-analyzer/rust-analyzer/issues/10464.
This patch picks up `lsp-types` 0.90.1, which serialises the
`SignatureInformation` and `ParameterInformation` with the right casing.
It also adds `activeSignature` field as part of the top-level signature
response. It keeps `activeParameter` at the top-level for backwards
compatibility.
10181: Begining of lsif r=HKalbasi a=HKalbasi
This PR adds a `lsif` command to cli, which can be used as `rust-analyzer lsif /path/to/project > dump.lsif`. It now generates a valid, but pretty useless lsif (only supports folding ranges). The propose of this PR is to discussing about the structure of lsif generator, before starting anything serious.
cc `@matklad` #8696#3098
Co-authored-by: hamidreza kalbasi <hamidrezakalbasi@protonmail.com>
10105: RfC: Use `todo!()` instead of `()` for missing fields r=jonas-schievink a=jo-so
Most commonly a field of a struct can be initialized with its default value than an empty tuple.
Co-authored-by: Jörg Sommer <joerg@jo-so.de>
10332: minor: Allow overwriting RUST_BACKTRACE for the server manually r=jonas-schievink a=Veykril
Trying to figure out why we aren't getting backtraces for windows builds from CI, this let's one set the backtraces to `FULL`
Might be cc https://github.com/rust-lang/rust/issues/87481
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
With this patch, in these examples
```rust
fn main() {
"⊞$0";
}
```
```rust
struct S {
д$0 u8
}
```
entering ':' character in `$0` places shouldn't cause panics.
The generated code with `()` doesn't compile in most of the cases. To signal
the developer there's something to do, fill in `todo!()`.
Because the file *missing_fields.rs* contains the string `todo!()` it needs
an exception for the test *check_todo*.
When dealing with proc macros, there are two very different kinds of
errors:
* first, usual errors of "proc macro panicked on this particular input"
* second, the proc macro server might day if the user, eg, kills it
First kind of errors are expected and are a normal output, while the
second kind are genuine IO-errors.
For this reason, we use a curious nested result here: `Result<Result<T,
E1>, E2>` pattern, which is 100% inspired by http://sled.rs/errors.html
