10417: feat(assist): add new assist to unwrap the result return type r=bnjjj a=bnjjj
do the opposite of assist "wrap the return type in Result"
Co-authored-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>
Co-authored-by: Coenen Benjamin <benjamin.coenen@hotmail.com>
10542: Use workspace cargo to fetch rust source's metadata r=lnicola a=Alexendoo
Previously the detected cargo is the global one, as it uses the
directory of the rust source which doesn't pick up the local override
This fixes the case in clippy where the local rust toolchain is a recent
nightly that has a 2021 edition Cargo.toml. The global (stable) cargo
returns an error attempting to parse it
Fixes#10445
Co-authored-by: Alex Macleod <alex@macleod.io>
10552: fix: Fix missing_fields diagnostic fix replacing wrong text ranges r=Veykril a=Veykril
Fixes#5393 by replacing the problematic behaviour there with a new "problem"
It replaces the correct range now, but it potentially discards the whitespace in the macro input. This is the best we can do currently until we get a formatter.
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
10543: Narrow add_missing_match_arms assist range r=Veykril a=antonfirsov
Contributes to #10220 with logic borrowed from #10267.
Note: if anyone has recommendations for further analyzers to check, I'm happy to (hard to do it on my own, I'm completely new to the language).
Co-authored-by: Anton Firszov <antonfir@gmail.com>
10491: Support nested type on replace if let with match r=k-nasa a=k-nasa
## Why
close: https://github.com/rust-analyzer/rust-analyzer/issues/8690
Now, Replacing if-let with match cant't output exhaustive patterns code.
This was because the `else` conversion used specific types (ex. Option, Result) instead of wildcards.
I thought it was more of a problem to generate non-exhaustive patterns than the benefits of using the concrete one.
How about using wildcards in `else`?
Is this change policy acceptable?
## What
- using wildcards on `make_else_arm`
- Change test cases
Co-authored-by: k-nasa <htilcs1115@gmail.com>
10546: feat: Implement promote_local_to_const assist r=Veykril a=Veykril
Fixes#7692, that is now one can invoke the `extract_variable` assist on something and then follow that up with this assist to turn it into a const.
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
10539: Add "generate delegate methods" assist r=Veykril a=yoshuawuyts
_Co-authored with `@rylev_.`
This patch adds a new assist: "generate delegate method" which creates a method that calls to a method defined on an inner field. Delegation is common when authoring newtypes, and having IDE support for this is the best way we can make this easier to author in Rust, bar adding language-level support for it. Thanks!
Closes#5944.
## Example
__before__
```rust
struct Age(u8);
impl Age {
fn age(&self) -> u8 {
self.0
}
}
struct Person {
ag$0e: Age,
}
```
__after__
```rust
struct Age(u8);
impl Age {
fn age(&self) -> u8 {
self.0
}
}
struct Person {
age: Age,
}
impl Person {
$0fn age(&self) -> u8 {
self.age.age()
}
}
```
Co-authored-by: Ryan Levick <me@ryanlevick.com>
Co-authored-by: Yoshua Wuyts <yoshuawuyts@gmail.com>
Previously the detected cargo is the global one, as it uses the
directory of the rust source which doesn't pick up the local override
This fixes the case in clippy where the local rust toolchain is a recent
nightly that has a 2021 edition Cargo.toml. The global (stable) cargo
returns an error attempting to parse it
Fixes#10445
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>
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>
10529: Generate `PartialOrd` implementations r=Veykril a=yoshuawuyts
_co-authored with `@rylev_`
This closes#5946 (which should've been closed already, lol). This PR makes it so we generate `PartialOrd` code implementations where possible. This is the last of Rust's built-in traits that was missing codegen.
After this has been merged we should look at moving the tests to a better spot, and maybe cleaning up the implementation somewhat (it's rather copy-pasty at the moment).
Either way, this finishes up the functionality. Thanks heaps!
Co-authored-by: Yoshua Wuyts <yoshuawuyts@gmail.com>
10532: Rename `descend_into_macros` Function per FIXME comment r=Veykril a=mirkoRainer
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.
I was prompted to do this per a FIXME comment, which is removed in this PR.
Co-authored-by: Mirko Rainer <mirkorainer@outlook.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.
10528: internal: Make selections in assists with trailing/leading whitespace more forgiving r=Veykril a=Veykril
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.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.
I don't like our macro tests -- they are brittle and don't inspire
confidence. I think the reason for that is that we try to unit-test
them, but that is at odds with reality, where macro expansion
fundamentally depends on name resolution.
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>
10440: Fix Clippy warnings and replace some `if let`s with `match` r=Veykril a=arzg
I decided to try fixing a bunch of Clippy warnings. I am aware of this project’s opinion of Clippy (I have read both [rust-lang/clippy#5537](https://github.com/rust-lang/rust-clippy/issues/5537) and [rust-analyzer/rowan#57 (comment)](https://github.com/rust-analyzer/rowan/pull/57#discussion_r415676159)), so I totally understand if part of or the entirety of this PR is rejected. In particular, I can see how the semicolons and `if let` vs `match` commits provide comparatively little benefit when compared to the ensuing churn.
I tried to separate each kind of change into its own commit to make it easier to discard certain changes. I also only applied Clippy suggestions where I thought they provided a definite improvement to the code (apart from semicolons, which is IMO more of a formatting/consistency question than a linting question). In the end I accumulated a list of 28 Clippy lints I ignored entirely.
Sidenote: I should really have asked about this on Zulip before going through all 1,555 `if let`s in the codebase to decide which ones definitely look better as `match` :P
Co-authored-by: Aramis Razzaghipour <aramisnoah@gmail.com>
10456: fix: Avoid cycle when lowering predicates for associated item lookup r=flodiebold a=jonas-schievink
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/10386
(the salsa bug persists, but this lets us avoid it by fixing the underlying bug)
This reimplements the rustc logic in b27661eb33/compiler/rustc_typeck/src/collect.rs (L556): When resolving an associated type `T::Item`, we've previously lowered all predicates that could affect `T`, but we actually have to look only at those predicates whose traits define an associated type of the right name.
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
