10603: fix: Don't resolve attributes to non attribute macros r=Veykril a=Veykril
Also changes `const`s to `static`s for `Limit`s as we have interior mutability in those(though only used with a certain feature flag enabled).
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
10563: feat: Make "Generate getter" assist use semantic info r=agluszak a=agluszak
This PR makes "Generate getter" assist use semantic info instead of dealing with types encoded as strings.
Getters for types which are:
- `Copy` no longer return references
- `AsRef<str>` (i.e. `String`) return `&str` (instead of `&String`)
- `AsRef<[T]>` (i.e. `Vec<T>`) return `&[T]` (instead of `&Vec<T>`)
- `AsRef<T>` (i.e. `Box<T>`) return `&T` (instead of `&Box<T>`)
- `Option<T>` return `Option<&T>` (instead of `&Option<T>`)
- `Result<T, E>` return `Result<&T, &E>` (instead of `&Result<T, E>`)
String, Vec, Box and Option were previously handled as special cases.
Closes#10295
Co-authored-by: Andrzej Głuszak <gluszak.andrzej@gmail.com>
10387: Move `IdxRange` into la-arena r=Veykril a=arzg
Currently, `IdxRange` (named `IdRange`) is located in `hir_def::item_tree`, when really it isn’t specific to `hir_def` and could become part of la-arena. The rename from `IdRange` to `IdxRange` is to maintain consistency with the naming convention used throughout la-arena (`Idx` instead of `Id`, `RawIdx` instead of `RawId`). This PR also adds a few new APIs to la-arena on top of `IdxRange` for convenience, namely:
- indexing into an `Arena` by an `IdxRange` and getting a slice of values back
- creating an `IdxRange` from an inclusive range
Currently this PR also exposes a new `Arena::next_idx` method to make constructing inclusive`IdxRange`s using `IdxRange::new` easier; however, it would in my opinion be better to remove this as it allows for easy creation of out-of-bounds `Idx`s, when `IdxRange::new_inclusive` mostly covers the same use-case while being less error-prone.
I decided to bump the la-arena version to 0.3.0 from 0.2.0 because adding a new `Index` impl for `Arena` turned out to be a breaking change: I had to add a type hint in `crates/hir_def/src/body/scope.rs` when one wasn’t necessary before, since rustc couldn’t work out the type of a closure parameter now that there are multiple `Index` impls. I’m not sure whether this is the right decision, though.
Co-authored-by: Aramis Razzaghipour <aramisnoah@gmail.com>
10600: minor: Make some functions non-generic r=Veykril a=lnicola
This reduces `text` size by 10192 bytes (0.064% 😢), with no apparent change in performance.
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
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>
