9955: fix: Rename fails on renaming definitions created by macros instead of renaming the macro invocation r=Veykril a=Veykril
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9855: feature: Destructure Tuple Assist r=Veykril a=Booksbaum
Part of #8673. This PR only handles tuples, not TupleStruct and RecordStruct.
Code Assist to destructure a tuple into its items:
* Should work in nearly all pattern positions, like let assignment, function parameters, match arms, for loops, and nested variables (`if let Some($0t) = Some((1,2))`)
-> everywhere `IdentPat` is allowed
* Exception: If there's a sub-pattern (``@`):`
```rust
if let t @ (1..=3, 1..=3) = ... {}
// ^
```
-> `t` must be a `Name`; `TuplePat` (`(_0, _1)`) isn't allowed
* inside subpattern is ok:
```rust
let t @ (a, _) = ((1,2), 3);
// ^
```
->
```rust
let t @ ((_0, _1), _) = ((1,2), 3);
```
* Assist triggers only at tuple declaration, not tuple usage.
(might be useful especially when it creates a sub-pattern (after ``@`)` and only changes the usage under cursor -- but not part of this PR).
### References
References can be destructured:
```rust
let t = &(1,2);
// ^
let v = t.0;
```
->
```rust
let (_0, _1) = &(1,2);
let v = _0;
```
BUT: `t.0` and `_0` have different types (`i32` vs. `&i32`) -> `v` has now a different type.
I think that's acceptable: I think the destructure assist is mostly used in simple, immediate scopes and not huge existing code.
Additional Notes:
* `ref` has same behaviour (-> `ref` is kept for items)
```rust
let ref t = (1,2);
// ^
```
->
```rust
let (ref _0, ref _1) = (1,2);
```
* Rust IntelliJ Plugin: doesn't trigger with `&` or `ref` at all
### mutable
```rust
let mut t = (1,2);
// ^
```
->
```rust
let (mut _0, mut _1) = (1,2);
```
and
```rust
let t = &mut (1,2);
// ^
```
->
```rust
let (_0, _1) = &mut (1,2);
```
Again: with reference (`&mut`), `t.0` and `_0` have different types (`i32` vs `&mut i32`).
And there's an additional issue with `&mut` and assignment:
```rust
let t = &mut (1,2);
// ^
t.0 = 9;
```
->
```rust
let (_0, _1) = &mut (1,2);
_0 = 9;
// ^
// mismatched types
// expected `&mut {integer}`, found integer
// consider dereferencing here to assign to the mutable borrowed piece of memory
```
But I think that's quite a niche use case, so I don't catch that (`*_0 = 9;`)
Additional Notes:
* Rust IntelliJ Plugin: removes the `mut` (`let mut t = ...` -> `let (_0, _1) = ...`), doesn't trigger with `&mut`
### Binding after ``@``
Destructure tuple in sub-pattern is implemented:
```rust
let t = (1,2);
// ^
let v = t.0;
let f = t.into();
```
->
```rust
let t @ (_0, _1) = (1,2);
let v = _0;
let f = t.into();
```
BUT: Bindings after ``@`` aren't currently in stable and require `#![feature(bindings_after_at)]` (though should be generally [available quite soon](https://github.com/rust-lang/rust/pull/85305#event-5072889913) (with `1.56.0`)).
But I don't know how to check for an enabled feature -> Destructure tuple in sub-pattern [isn't enabled](a4ee6c7954/crates/ide_assists/src/handlers/destructure_tuple_binding.rs (L32)) yet.
* When Destructure in sub-pattern is enabled there are two assists:
* `Destructure tuple in place`:
```rust
let t = (1,2);
// ^
```
->
```rust
let (_0, _1) = (1,2);
let v = _0;
let f = /*t*/.into();
```
* `Destructure tuple in sub-pattern`:
```rust
let t = (1,2);
// ^
let v = t.0;
let f = t.into();
```
->
```rust
let t @ (_0, _1) = (1,2);
let v = _0;
let f = t.into();
```
* When Destructure in sub-pattern is disabled, only the first one is available and just named `Destructure tuple`
<br/>
<br/>
### Caveats
* Unlike in #8673 or IntelliJ rust plugin, I'm not leaving the previous tuple name at function calls.
**Reasoning**: It's not too unlikely the tuple variable shadows another variable. Destructuring the tuple while leaving the function call untouched, results in still a valid function call -- but now with another variable:
```rust
let t = (8,9);
let t = (1,2);
// ^
t.into()
```
=> Destructure Tuple
```rust
let t = (8,9);
let (_0, _1) = (1,2);
t.into()
```
`t.into()` is still valid -- using the first tuple.
Instead I comment out the tuple usage, which results in invalid code -> must be handled by user:
```rust
/*t*/.into()
```
* (though that might be a biased decision: For testing I just declared a lot of `t`s and quite ofen in lines next to each other...)
* Issue: there are some cases that results in still valid code:
* macro that accept the tuple as well as no arguments:
```rust
macro_rules! m {
() => { "foo" };
($e:expr) => { $e; "foo" };
}
let t = (1,2);
m!(t);
m!(/*t*/);
```
-> both calls are valid ([test](a4ee6c7954/crates/ide_assists/src/handlers/destructure_tuple_binding.rs (L1474)))
* Probably with tuple as return value. Changing the return value most likely results in an error -- but in another place; not where the tuple usage was.
-> not sure that's the best way....
Additional the tuple name surrounded by comment is more difficult to edit than just the name.
* Code Assists don't support snippet placeholder, and rust analyzer just the first `$0` -> unfortunately no editing of generated tuple item variables. Cursor (`$0`) is placed on first generated item.
<br/>
<br/>
### Issues
* Tuple index usage in macro calls aren't converted:
```rust
let t = (1,2);
// ^
let v = t.0;
println!("{}", t.0);
```
->
```rust
let (_0, _1) = (1,2);
let v = _0;
println!("{}", /*t*/.0);
```
([tests](a4ee6c7954/crates/ide_assists/src/handlers/destructure_tuple_binding.rs (L1294)))
* Issue is:
[name.syntax()](a4ee6c7954/crates/ide_assists/src/handlers/destructure_tuple_binding.rs (L242-L244)) in each [usage](a4ee6c7954/crates/ide_assists/src/handlers/destructure_tuple_binding.rs (L108-L113)) of a tuple is syntax & text_range in its file.
EXCEPT when tuple usage is in a macro call (`m!(t.0)`), the macro is expanded and syntax (and range) is based on that expanded macro, not in actual file.
That leads to several things:
* I cannot differentiate between calling the macro with the tuple or with tuple item:
```rust
macro_rules! m {
($t:expr, $i:expr) => { $t.0 + $i };
}
let t = (1,2);
m!(t, t.0);
```
-> both `t` usages are resolved as tuple index usage
* Range of resolved tuple index usage is in expanded macro, not in actual file
-> don't know where to replace index usage
-> tuple items passed into a macro are ignored, and only the tuple name itself is handled (uncommented)
* I'm not checking if the generated names conflict with already existing variables.
```rust
let _0 = 42; // >-|
let t = (1,2); // |
let v = _0; // <-|
// ^ 42
```
=> deconstruct tuple
```rust
let _0 = 42;
let (_0, _1) = (1,2); // >-|
let v = _0; // <-|
// ^ now 1
```
* I tried to get the scope at tuple declaration and its usages. And then iterate all names with [`process_all_names`](145b51f9da/crates/hir/src/semantics.rs (L935)). But that doesn't find all local names for declarations (`let t = (1,2)`) (for usages it does)
* This isn't unique to this Code Assist, but happen in others too (like `extract into variable` or `extract into function`). But here a name conflict is more likely (when destructuring multiple tuples, for examples nested ones (`let t = ((1,2),3)` -> `let (_0, _1) = ...` -> `let ((_0, _1), _1) = ...` -> error))
* IntelliJ rust plugin does handle this (-> name is `_00`)
Co-authored-by: BooksBaum <15612932+Booksbaum@users.noreply.github.com>
Note:
2nd Assist description is moved down: generated doc tests extracts now
all tests (previously only the first one). But it uses the first
`Assist` name -- which is the wrong one for the 2nd test. And 2nd assist
is currently disabled -> would fail anyway.
9921: Only add entries to SourceToDef dynmaps when they come from the same file r=matklad a=Veykril
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/9919
Running the test as described in the issue I do not get any eprintln output at all anymore.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
cargo llvm-lines shows that path_to_error bloats the code. I don't think
I've needed this functionality recently, seems that we've fixed most of
the serialization problems. So let's just remove it. Should be easy to
add back if we ever need it, and it does make sense to keep the
`from_json` function around.
9896: internal: Only complete type annotations for patterns in function params r=Veykril a=Veykril
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
Previously, we only inverted comparison operators (< and the like) if
the type implemented Ord. This doesn't make sense: if `<` works, then
`>=` will work as well!
Extra semantic checks greatly reduce robustness and predictability of
the assist, it's better to keep things simple.
9871: Jump to generated func r=mahdi-frms a=rylev
Worked on this with `@yoshuawuyts.`
We thought we ran into an issue with the `generate_function` assist where the code was not being generated in a certain situations. However, it wasn't actually a bug just a very confusing implementation where the cursor is not moved to the newly generated function. This happened when the return type was successfully inferred (and not unit). The function would be generated, but selection would not be changed.
This can be very confusing: If the function is generated somewhat far from where the assist is being invoked, the user never sees that the code was generated (nor are they given the chance to actually implement the function body).
This PR makes it so that the cursor is _always_ moved to somewhere in the newly generated function. In addition, if we can infer unit as the type, then we do not still generate `-> ()` as the return type. Instead, we simply omit the return type.
This means the selection will move to either one of two places:
* A generated `-> ()` return type when we cannot successfully infer the return type.
* The `todo!()` body when we can successfully infer the return type.
Co-authored-by: Ryan Levick <me@ryanlevick.com>
9863: feat: Generate default trait fn impl when generating `PartialEq` r=yoshuawuyts a=yoshuawuyts
Implements a default trait function body when generating the `PartialEq` trait for a type. Thanks!
r? `@veykril`
Co-authored-by: Yoshua Wuyts <yoshuawuyts@gmail.com>
9836: Refactor: quick clean-up of iteration idioms in the `vfs` crate r=matklad a=Some-Dood
This PR cleans up some of the iteration idioms used in the `vfs` crate. Most of the changes simply converted `for` loops into their `std::iter::Iterator`-method counterpart. Other changes required some inversion of logic to accommodate for better short-circuiting. Overall, there should be no behavioral changes. If there are any stylistic issues, I will gladly adhere to them and adjust the PR accordingly. Thanks!
Co-authored-by: Basti Ortiz <39114273+Some-Dood@users.noreply.github.com>
9828: Remove dependency on the system graphviz when rendering crate graph r=lnicola a=p32blo
This PR removes the need for having `graphviz` installed on the user system by using the `d3-graphviz` npm package.
The responsibility of rendering the svg output is moved to the extension while the rust side only handles the generation of the dot file.
This change also brings the following additional features:
- Allow zooming the view
- Ctrl+click to reset the zoom
- Adjust the color scheme to dark themes
- Works on any platform without installing graphviz locally
---
I’m not sure if this fits what you had in mind for the crates graph feature but I decided to submit it anyway to see if this is useful to anyone else.
A potential downside might be that it increases the extension size ( haven’t checked) but this feature already required the installation of graphviz on the user side, so the cost is just moved explicitly to the extension.
Feel free to make any suggestion or comments.
Co-authored-by: André Oliveira <p32blo@gmail.com>
9846: feat: Generate default trait fn impl when generating `Clone` r=Veykril a=yoshuawuyts
Implements a default trait function body when generating the `Clone` trait for a type. Thanks!
r? `@\veykril`
Co-authored-by: Yoshua Wuyts <yoshuawuyts@gmail.com>
9830: Enable more assists to generate default trait body impls r=Veykril a=yoshuawuyts
Enable more assists to benefit from trait body generation. Follow-up to #9825 and #9814.
__edit:__ I'd like to move the existing tests to this new file too, but I'll do that in a follow-up PR.
Co-authored-by: Yoshua Wuyts <yoshuawuyts@gmail.com>
9804: Generate method from call r=matklad a=mahdi-frms
Needs a bit of refactoring. Tests also should be added.
Co-authored-by: mahdi-frms <mahdif1380@outlook.com>
9825: Generate default impl when converting #[derive(Default)] to manual impl r=Veykril a=yoshuawuyts
Similar to https://github.com/rust-analyzer/rust-analyzer/pull/9814, but for `#[derive(Default)]`. Thanks!
## Follow-up steps
I've added the tests inside `handlers/replace_derive_with_manual_impl.rs` again, but I'm planning a follow-up PR to extract these to `utils/` so we can share them between assists - and maybe even add another assist just for the purpose of testing these impls (e.g. `generate_default_trait_body`).
The step after _that_ is likely to fill out the remaining traits, so we can make it so whenever RA auto-completes a trait which also can be derived, we provide a default function body.
Co-authored-by: Yoshua Wuyts <yoshuawuyts@gmail.com>
From the dawn of time, when dinosaurs roamed the and we didn't have
hierarchical profiling, there was the `latest_requests` infra we used to
track the time of ten last requests.
Today, no one is actually using it and, what's more, it itself became
pretty useless -- LSP grew way more chatty, and 10 requests don't really
paint any kind of picture.
Personally, it's been years since I last looked at latest requests in
the status output.
So, let's remove a tiny bit of state from the big ball of complexity
that is `GlobalState` and `main_loop`!
Today, rust-analyzer (and rustc, and bat, and IntelliJ) fail badly on
some kinds of maliciously constructed code, like a deep sequence of
nested parenthesis.
"Who writes 100k nested parenthesis" you'd ask?
Well, in a language with macros, a run-away macro expansion might do
that (see the added tests)! Such expansion can be broad, rather than
deep, so it bypasses recursion check at the macro-expansion layer, but
triggers deep recursion in parser.
In the ideal world, the parser would just handle deeply nested structs
gracefully. We'll get there some day, but at the moment, let's try to be
simple, and just avoid expanding macros with unbalanced parenthesis in
the first place.
closes#9358
We generally avoid "syntax only" helper wrappers, which don't do much:
they make code easier to write, but harder to read. They also make
investigations harder, as "find_usages" needs to be invoked both for the
wrapped and unwrapped APIs
9814: Generate default impl when converting `#[derive(Debug)]` to manual impl r=yoshuawuyts a=yoshuawuyts
This patch makes it so when you convert `#[derive(Debug)]` to a manual impl, a default body is provided that's equivalent to the original output of `#[derive(Debug)]`. This should make it drastically easier to write custom `Debug` impls, especially when all you want to do is quickly omit a single field which is `!Debug`.
This is implemented for enums, record structs, tuple structs, empty structs - and it sets us up to implement variations on this in the future for other traits (like `PartialEq` and `Hash`).
Thanks!
## Codegen diff
This is the difference in codegen for record structs with this patch:
```diff
struct Foo {
bar: String,
}
impl fmt::Debug for Foo {
fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
- todo!();
+ f.debug_struct("Foo").field("bar", &self.bar).finish()
}
}
```
Co-authored-by: Irina Shestak <shestak.irina@gmail.com>
Co-authored-by: Yoshua Wuyts <yoshuawuyts@gmail.com>
Co-authored-by: Yoshua Wuyts <yoshuawuyts+github@gmail.com>
9808: fix: Look for enum variants and trait assoc functions when looking for lang items r=matklad a=Veykril
Examples for lang enum variants are the `Option` variants.
Assoc trait functions aren't being seen since they aren't declared in the direct module scope.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9785: feature: Add completion for struct literals in which all fields are visible. r=Veykril a=Afourcat
This PR adds a new completion for struct literal.
It Implements the feature discussed in the issue #9610.
This PR introduce a repetition in the source files `crates/ide_completion/render/pattern.rs` and `crates/ide_completion/render/struct_literal.rs` that may be fix in another PR.
Co-authored-by: Alexandre Fourcat <afourcat@gmail.com>
Fix ide_completion tests.
Move 'complete_record_literal' call to the main completion function.
Fix a rendering bug when snippet not available.
Checks if an expression is expected before adding completion for struct literal.
Move 'completion struct literal with private field' test to 'expressions.rs' test file.
Update 'expect' tests with new check in 'complete record literal'.
9734: semantic highlighting: add reference hlmod r=matklad a=jhgg
This PR adds the "reference" highlight modifier!
I basically went around and looked for `HlMod::Mutable` to find the callsites to add a reference. I think these all make sense!
Co-authored-by: Jake Heinz <jh@discordapp.com>
Co-authored-by: Jake <jh@discordapp.com>
9773: internal: Improve `extract_function` assist r=Veykril a=Veykril
- fix: It doesn't try to overwrite parts of selected comments any longer
- fix: It doesn't wrap tail expressions and return types in a result or option unnecessarily
- feat?: It now adds a `const` modifier to the created function if extract somethings from a const context
Fixes#7840
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9764: fix: Don't use the module as the candidate node in fuzzy path flyimport r=Veykril a=Veykril
The problem was that the candidate node is whats being used for the scope, so using an inline module will yield the surrounding scope of the module instead of the scope of the module itself.
Also seems to fix the problem in this comment https://github.com/rust-analyzer/rust-analyzer/issues/9760#issuecomment-891125674, though I could not recreate that in a test for some reason.
Fixes#9760
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9751: Make `LoadCargoConfig`, `fn load_workspace_at` & `fn load_workspace` public again r=matklad a=regexident
This [commit](b24f816c0d) which restricted the visibility of `LoadCargoConfig`, `fn load_workspace_at` & `fn load_workspace` unfortunately effectively rendered every crate/tool that uses rust-analyzer as a library dead in the water.
On of such tools is [cargo-modules](https://github.com/regexident/cargo-modules), a tool for generating tree/graph visualizations of one's Rust project and is powered by rust-analyzer as a library.
For more context see the PRs that introduced those types/functions and made them `pub`:
- https://github.com/rust-analyzer/rust-analyzer/pull/7595
- https://github.com/rust-analyzer/rust-analyzer/pull/7690
If kept as is rust-analyzer would effectively no longer be usable as a library.
cc `@SomeoneToIgnore`
Co-authored-by: Vincent Esche <regexident@gmail.com>
9752: feature: Declare proc-macro dependent crates in `rust-project.json` r=matklad a=tobywf
This adds the `is_proc_macro` flag in `rust-project.json`. By default, this is `false` and not required, so existing projects won't break/have the same behavior as before this change. If the flag is true, a dependency to the `proc_macro` sysroot crate is added (if it exists), so that rust-analyzer can resolve those imports.
This fixes#9726 .
I've also added some tests in the second commit. The first is a smoke test for a basic, minimal `rust-project.json` file. The second is a more targeted test for the flag. Both tests depend on the fake sysroot (a bunch of directories in the correct layout with empty `lib.rs` files), and also on `env!("CARGO_MANIFEST_DIR")` being an absolute path. I'm not sure if the later assumption is valid on all platforms. I wanted to at least try and add tests, but I'm happy to rework them or remove them if you don't think that's the way to go.
(You can license/relicense my contribution in any way you wish without contacting me.)
Co-authored-by: Toby Fleming <sourcecode@tobywf.com>
9746: internal: add API to check what are the max limits in practice r=matklad a=matklad
bors r+
🤖
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
9739: generate function assist favors deref cmpt types r=matklad a=mahdi-frms
Fixes#9713
Although that's still not relying on sematic info.
Co-authored-by: mahdi-frms <mahdif1380@outlook.com>
Some features of rust-analyzer requires support for custom commands on
the client side. Specifically, hover & code lens need this.
Stock LSP doesn't have a way for the server to know which client-side
commands are available. For that reason, we historically were just
sending the commands, not worrying whether the client supports then or
not.
That's not really great though, so in this PR we add infrastructure for
the client to explicitly opt-into custom commands, via `extensions`
field of the ClientCapabilities.
To preserve backwards compatability, if the client doesn't set the
field, we assume that it does support all custom commands. In the
future, we'll start treating that case as if the client doesn't support
commands.
So, if you maintain a rust-analyzer client and implement
`rust-analyzer/runSingle` and such, please also advertise this via a
capability.
