Prefer standard library paths over shorter extern deps re-exports
This should generally speed up path finding for std items as we no longer bother looking through all external dependencies. It also makes more sense to prefer importing std items from the std dependencies directly.
Fixes https://github.com/rust-lang/rust-analyzer/issues/17540
Fix path resolution for child mods of those expanded by `include!`
Child modules wouldn't use the correct candidate paths due to a branch that doesn't seem to be doing what it's intended to do. Removing the branch fixes the problem and all existing test cases pass.
Having no knowledge of how any of this works, I believe this fixes#17645. Using another test that writes the included mod directly into `lib.rs` instead, I found the difference can be traced to the candidate files we use to look up mods. A separate branch for if the file comes from an `include!` macro doesn't take into account the original mod we're contained within:
```rust
None if file_id.macro_file().map_or(false, |it| it.is_include_macro(db.upcast())) => {
candidate_files.push(format!("{}.rs", name.display(db.upcast())));
candidate_files.push(format!("{}/mod.rs", name.display(db.upcast())));
}
```
I'm not sure why this branch exists. Tracing the branch back takes us to 3bb9efb but it doesn't say *why* the branch was added. The test case that was added in this commit passes with the branch removed, so I think it's just superfluous at this point.
Child modules wouldn't use the correct candidate paths due to a branch that doesn't seem to be doing what it's intended to do. Removing the branch fixes the problem and all existing test cases pass.
fix: Panic in debug profile for tuple deconstruct with arity mismatch
Fixes#17585, which doesn't affect daily use cases but quite annoying in development of r-a itself like writing tests.
This PR applies similar approach as in #17534, skipping match usefulness check for patterns containing errors
The commands `editor.action.triggerParameterHints` and
`editor.action.rename` are now renamed to
`rust-analyzer.triggerParameterHints` and `rust-analyzer.rename`
This change helps make it clear that these commands are specific to
rust-analyzer and not part of the default set of commands provided by
VSCode.
Fixes: https://github.com/rust-lang/rust-analyzer/issues/17644
Avoid ref when using format! in compiler
Clean up a few minor refs in `format!` macro, as it has a performance cost. Apparently the compiler is unable to inline `format!("{}", &variable)`, and does a run-time double-reference instead (format macro already does one level referencing). Inlining format args prevents accidental `&` misuse.
See https://github.com/rust-lang/rust-clippy/issues/10851
Some more small salsa memory improvements
This does limit our lru limits to 2^16 but if you want to set them higher than that you might as well not set them at all. Also makes `LRU` opt-in per query now, allowing us to drop all the unnecessary LRU stuff for most queries
Clean up a few minor refs in `format!` macro, as it has a performance cost. Apparently the compiler is unable to inline `format!("{}", &variable)`, and does a run-time double-reference instead (format macro already does one level referencing). Inlining format args prevents accidental `&` misuse.
feature: teach rust-analyzer to discover `linked_projects`
This PR's been a long-time coming, but like the title says, it introduces server-side project discovery and removes the extension hooks I previously introduced. I don't think this PR is ready to land, but here are the things I'm feeling squishy about:
- I don't think I like the idea of introducing the `cargo-metadata` command-but-for-everything-else in the `flycheck` module, but the progress reporting infrastructure was too convenient to pass up. Happy to move it elsewhere.
Here are the things I _know_ I need to change:
- For progress reporting, I'm extracting from a `serde_json::Value` that corresponds to `tracing_subsciber::fmt::Layer`'s JSON output. I'd like to make this a bit more structured/documented than the current nonsense I wrote.
- The progress reporting currently hardcodes "Buck"; it should be deriving that from the previously mentioned more-structured-output.
- This doesn't handle *reloading* when a corresponding buildfile is changed. It should be doing that.
<details>
<summary>Anyway, here's a video of rust-analyzer discovering a Buck target.</summary>
https://github.com/rust-lang/rust-analyzer/assets/2067774/be6cd9b9-2c9a-402d-847f-05f860a91df1
</details>
feat: Add incorrect case diagnostics for enum variant fields and all variables/params
Updates the incorrect case diagnostic to check:
1. Fields of enum variants. Example:
```rust
enum Foo {
Variant { nonSnake: u8 }
}
```
2. All variable bindings, instead of just let bindings and certain match arm patters. Examples:
```rust
match 1 { nonSnake => () }
match 1 { nonSnake @ 1 => () }
match 1 { nonSnake1 @ nonSnake2 => () } // slightly cursed, but these both introduce new
// bindings that are bound to the same value.
const ONE: i32 = 1;
match 1 { nonSnake @ ONE } // ONE is ignored since it is not a binding
match Some(1) { Some(nonSnake) => () }
struct Foo { field: u8 }
match (Foo { field: 1 } ) {
Foo { field: nonSnake } => ();
}
struct Foo { nonSnake: u8 } // diagnostic here, at definition
match (Foo { nonSnake: 1 } ) { // no diagnostic here...
Foo { nonSnake } => (); // ...or here, since these are not where the name is introduced
}
for nonSnake in [] {}
struct Foo(u8);
for Foo(nonSnake) in [] {}
```
3. All parameter bindings, instead of just top-level binding identifiers. Examples:
```rust
fn func(nonSnake: u8) {} // worked before
struct Foo { field: u8 }
fn func(Foo { field: nonSnake }: Foo) {} // now get diagnostic for nonSnake
```
This is accomplished by changing the way binding identifier patterns are filtered:
- Previously, all binding idents were skipped, except a few classes of "good" binding locations that were checked.
- Now, all binding idents are checked, except field shorthands which are skipped.
Moving from a whitelist to a blacklist potentially makes the analysis more brittle:
If new pattern types are added in the future where ident pats don't introduce new names, then they may incorrectly create diagnostics.
But the benefit of the blacklist approach is simplicity: I think a whitelist approach would need to recursively visit patterns to collect renaming candidates?
Trigger VSCode to rename after extract variable assist is applied
When the user applies the "Extract Variable" assist, the cursor is
positioned at the newly inserted variable. This commit adds a command
to the assist that triggers the rename action in VSCode. This way, the
user can quickly rename the variable after applying the assist.
Fixes part of: #17579https://github.com/user-attachments/assets/4cf38740-ab22-4b94-b0f1-eddd51c26c29
I haven't yet looked at the module or function extraction assists yet.
use "bootstrap" instead of "rustbuild" in comments and docs
Let's stick with the single name "bootstrap" to refer to the bootstrap project to avoid confusion. This should make it clearer, especially for new contributors.
When the user applies the "Extract Variable" assist, the cursor is
positioned at the newly inserted variable. This commit adds a command
to the assist that triggers the rename action in VSCode. This way, the
user can quickly rename the variable after applying the assist.
Fixes part of: #17579
feat: do not add new enum if it already exists
## Summary
This PR introduces a check for the existence of another enum within the current scope, and if it exist, we skip `add_enum_def`.
## Why?
Currently, when using the `bool_to_enum` assist more than once, it is possible to add multiple enum definitions. For example, the following snippet,
```rs
#[derive(PartialEq, Eq)]
enum Bool {
True,
False,
}
fn main() {
let a = Bool::True;
let b = true;
println!("Hello, world!");
}
```
will be transformed into,
```rs
#[derive(PartialEq, Eq)]
enum Bool {
True,
False,
}
#[derive(PartialEq, Eq)]
enum Bool {
True,
False,
}
fn main() {
let a = Bool::True;
let b = Bool::True;
println!("Hello, world!");
}
```
This can be annoying for users to clean up.
Add `f16` and `f128` support
Adds `f16` and `f128` support, using the `rustc_apfloat` library (also used by `rustc`) for parsing/arithmetic/displaying since the types aren't stable yet so can't be used by rust-analyzer itself.
Issue: #17451
