fix: Report both IO errors and main_loop errors
If rust-analyzer receives a malformed LSP request, the IO thread terminates with a meaningful error, but then closes the channel.
Once the channel has closed, the main_loop also terminates, but it only has RecvError and can't show a meaningful error. As a result, rust-analyzer would incorrectly claim that the client forgot to shutdown.
```
$ buggy_lsp_client | rust-analyzer
Error: client exited without proper shutdown sequence
```
Instead, include both error messages when the server shuts down.
fix: Report all LSP protocol errors with invalid_data
Previously we did not use invalid_data for serde errors, making it harder to understand errors when the client sends malformed data to the server.
If rust-analyzer receives a malformed LSP request, the IO thread
terminates with a meaningful error, but then closes the channel.
Once the channel has closed, the main_loop also terminates, but it
only has RecvError and can't show a meaningful error. As a result,
rust-analyzer would incorrectly claim that the client forgot to
shutdown.
```
$ buggy_lsp_client | rust-analyzer
Error: client exited without proper shutdown sequence
```
Instead, include both error messages when the server shuts down.
Fix source_range for INT_NUMBER in completion
fix#17179.
Previously r-a use `TextRange::empty(self.position.offset)` as `source_range` for `INT_NUMBER`, so the `text_edit` would always be an insertion, which results in #17179.
This PR changed it by using `text_range` of `original_token` (same as `IDENT`).
Fix: Lifetime's Bound Var Debrujin Index in Dyn Traits
Surely fixes#17182
I have tried running the analysis-stats in some of the repos mentioned in #17080. No panic in almost all of them.
Fix Run lens showing when lenses are disabled
I have disabled Rust Analyzer lenses in my VSCode settings, but noticed that the `Run` lens still showed. This surprised me, as the docs for `lens.run.enable` [state that it only applies when `lens.enable` is set](25f59be62f/crates/rust-analyzer/src/config.rs (L353-L355)). I then found that where we set `LensConfig::run`, we don't check `lens_enable` like for the other settings. [We did this previously](eab385e1f6/crates/rust-analyzer/src/config.rs (L1649)), so this seems like a regression from refactoring. This PR tries to fix that.
The documentation for `lens.run.enable` states that it only applies
when `lens.enable` is set. However, the config setting whether to show
the Run lens did not check `lens.enable`, so the Run lens would show
even though lenses were disabled.
Update `rust-analyzer` to use `windows-sys` crate
I noticed that the `rust-analyzer` project already depends on `windows-sys`. This update merely replaces the remaining direct dependencies on the older `winapi` crate with `windows-sys` dependencies.
Originally posted here: https://github.com/rust-lang/rust/pull/124578
fix: Tracing span names should match function names
When viewing traces, it's slightly confusing when the span name doesn't match the function name. Ensure the names are consistent.
(It might be worth moving most of these to use `#[tracing::instrument]` so the name can never go stale. `@davidbarsky` suggested that is marginally slower, so I've just done the simple change here.)
When viewing traces, it's slightly confusing when the span name doesn't
match the function name. Ensure the names are consistent.
(It might be worth moving most of these to use #[tracing::instrument]
so the name can never go stale. @davidbarsky suggested that is marginally
slower, so I've just done the simple change here.)
feature: Make generate function assist generate a function as a constructor if the generated function has the name "new" and is an asscociated function.
close#17050
This PR makes `generate function assist` generate a function as a constructor if the generated function has the name "new" and is an asscociated function.
If the asscociate type is a record struct, it generates the constructor like this.
```rust
impl Foo {
fn new() -> Self {
Self { field_1: todo!(), field_2: todo!() }
}
}
```
If the asscociate type is a tuple struct, it generates the constructor like this.
```rust
impl Foo {
fn new() -> Self {
Self(todo!(), todo!())
}
}
```
If the asscociate type is a unit struct, it generates the constructor like this.
```rust
impl Foo {
fn new() -> Self {
Self
}
}
```
If the asscociate type is another adt, it generates the constructor like this.
```rust
impl Foo {
fn new() -> Self {
todo!()
}
}
```
