Commit Graph

18974 Commits

Author SHA1 Message Date
mahdi-frms
c1edbfbacc better assist label 2021-08-22 12:31:16 +04:30
bors[bot]
8cd171cd94
Merge #9978
9978: fix: Expand attributes recursively in expand_macro r=Veykril a=Veykril

bors r+

Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
2021-08-21 21:26:00 +00:00
Lukas Wirth
2f179adc41 Expand attributes recursively in expand_macro 2021-08-21 23:24:12 +02:00
bors[bot]
62837d7b1b
Merge #9976
9976: fix: Do not show functional update completion when already qualified r=Veykril a=Veykril

Fixes #9964
bors r+

Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
2021-08-21 18:45:50 +00:00
Lukas Wirth
833de22d0b fix: Do not show functional update completion when already qualified 2021-08-21 20:45:15 +02:00
bors[bot]
9e3517f8f3
Merge #9975
9975: minor: Fix panic caused by #9966 r=flodiebold a=flodiebold

Chalk can introduce new type variables when doing lazy normalization, so we have to do the proper 'fudging' after all.

Co-authored-by: Florian Diebold <flodiebold@gmail.com>
2021-08-21 18:07:36 +00:00
Florian Diebold
df77e2448c Fix panic caused by #9966
Chalk can introduce new type variables when doing lazy normalization, so
we have to do the proper 'fudging' after all.
2021-08-21 20:07:07 +02:00
Lukas Wirth
5fb8c0ddfd Remove MappedSubtree 2021-08-21 18:19:18 +02:00
Lukas Wirth
177c70128c Map attribute input tokens correctly 2021-08-21 18:13:41 +02:00
bors[bot]
337ccc75a1
Merge #9973
9973: Handle coercion on binary operator RHS r=flodiebold a=lnicola

Closes #9968
CC #8961

Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
2021-08-21 16:10:04 +00:00
Laurențiu Nicola
104d6124d7 Handle coercion on binary operator RHS 2021-08-21 17:54:45 +03:00
mahdi-frms
50923ad741 func gen: seperate generation form position(3) 2021-08-21 19:13:14 +04:30
bors[bot]
19348bc478
Merge #9908
9908: fix check of the toolchain's path r=lnicola a=gfreezy

fixed #9907

Co-authored-by: Alex.F <gfreezy@gmail.com>
2021-08-21 13:41:09 +00:00
mahdi-frms
1ac9400100 func gen: seperate generation form position(2) 2021-08-21 17:31:37 +04:30
bors[bot]
3f4c515223
Merge #9966
9966: fix: Determine expected parameters from expected return in calls r=flodiebold a=flodiebold

Second attempt 😅 

Fixes #9560 

Co-authored-by: Florian Diebold <flodiebold@gmail.com>
2021-08-21 12:35:26 +00:00
Florian Diebold
1791a35f9f Determine expected parameters from expected return in calls
Fixes #9560
2021-08-21 14:33:31 +02:00
Florian Diebold
cd64353288 Adapt tests for correct behavior 2021-08-21 13:35:36 +02:00
Florian Diebold
5cff355059 Add another test 2021-08-21 13:35:34 +02:00
bors[bot]
6f41053ede
Merge #9965
9965: minor: Don't ask for the builtin attribute input twice r=Veykril a=Veykril

`tt` and `item` here were the same, I misunderstood what the main input for attributes was in #9943
bors r+

Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
2021-08-21 10:56:09 +00:00
Lukas Wirth
cee02673d1 Don't ask for the builtin attribute input twice 2021-08-21 12:55:05 +02:00
bors[bot]
4aa2a44a55
Merge #9962
9962: Add empty-body check to replace_match_with_if_let and re-prioritize choices r=elkowar a=elkowar

This PR changes some behaviour of the `replace_match_with_if_let` ide-assist.
Concretely, it makes two changes:

it introduces a check for empty expression bodies. This means that checks of the shape
```rs
match x {
  A => {}
  B => {
    println!("hi");
  }
}
```
will prefer to use the B branch as the first (and only) variant.

It also reprioritizes the importance of "happy" and "sad" patterns.
Concretely, if there are reasons to prefer having the sad pattern be the first (/only) pattern,
it will follow these.
This means that in the case of 
```rs
match x {
  Ok(_) => {
    println!("Success");
  }
  Err(e) => {
    println!("Failure: {}", e);
  }
}
```
the `Err` variant will correctly be used as the first expression in the generated if.
Up until now, the generated code was actually invalid, as it would generate
```rs
if let Ok(_) = x {
  println!("Success");
} else {
  println!("Failure: {}", e);
}
```
where `e` in the else branch is not defined.


Co-authored-by: elkowar <5300871+elkowar@users.noreply.github.com>
2021-08-21 10:12:17 +00:00
elkowar
e47c9743cf
Fix smaller nitpicks 2021-08-21 12:02:21 +02:00
elkowar
7cff930393
Use NameClass::classify to check for ConstReference 2021-08-21 11:11:27 +02:00
elkowar
75f0701211
Add heuristic to determine type of IdentPat, make check for empty expressions correct 2021-08-21 11:00:43 +02:00
mahdi-frms
87439b1d6a func gen: seperate generation form position(1) 2021-08-21 13:29:15 +04:30
mahdi-frms
e2c233a42b simplify 2021-08-21 11:52:07 +04:30
bors[bot]
13bbed7c16
Merge #9963
9963: fix: resolve core::arch module r=matklad a=matklad

bors r+
🤖

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
2021-08-20 14:02:08 +00:00
Aleksey Kladov
4924c24d91 fix: resolve core::arch module
See https://users.rust-lang.org/t/rust-analyzer-unable-to-resolve-target-specific-module/63797/4?u=matklad

The fix is to put all sysroot crates into the same source root
2021-08-20 17:01:27 +03:00
elkowar
d6695286ee
Add empty-body check to replace_match_with_if_let and re-prioritize choices 2021-08-20 15:20:54 +02:00
bors[bot]
3004f2ec90
Merge #9961
9961: internal: prep to 2021 edition r=matklad a=matklad

bors r+
🤖

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
2021-08-20 13:20:43 +00:00
Aleksey Kladov
1850849325 internal: prep to 2021 edition 2021-08-20 16:20:18 +03:00
bors[bot]
2fbe1c9934
Merge #9960
9960: internal: Use ExpandResult in all TokenExpanders r=Veykril a=Veykril

bors r+

Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
2021-08-20 12:36:36 +00:00
Lukas Wirth
82728eb757 Switch AstDatabase::exapnd_proc_macro to ExpandResult 2021-08-20 14:34:46 +02:00
Lukas Wirth
269de9abe3 Switch BuiltinDeriveExpander::expand to ExpandResult 2021-08-20 14:28:36 +02:00
bors[bot]
da5a5ba378
Merge #9943
9943: fix: Do not replace items annotated with builtin attrs with the attr input r=Veykril a=Veykril

This causes runnables to work for paths that actually resolve to the `test` attribute now.
![Code_aUhX1KQfw3](https://user-images.githubusercontent.com/3757771/129917168-bd9ed3f8-3a08-49d2-930a-4b93efaa8acf.png)

Prior to this we replaced items annotated with builtin attributes by the attribute input instead of the item in our dummy expansion which is why the fully written path didn't work as we actually discarded the item while `test` was just ignored.

Fixes #9935

Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
2021-08-20 11:57:28 +00:00
Lukas Wirth
557df6ff3f Use correct HirFileId in find_related_test 2021-08-20 13:50:40 +02:00
Lukas Wirth
7342dcf0b0 Fix runnables not seeing test and bench attributes 2021-08-20 13:50:06 +02:00
Lukas Wirth
351cec0cb4 Do not replace items annotated with builtin attrs with the attr input 2021-08-20 13:50:06 +02:00
bors[bot]
8dd3a71730
Merge #9955
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>
2021-08-19 22:13:09 +00:00
Lukas Wirth
c67ecbebc4 Rename fails on renaming definitions created by macros 2021-08-20 00:12:47 +02:00
bors[bot]
59aa091866
Merge #9855
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:
![Destructure_Tuple_Assist](https://user-images.githubusercontent.com/15612932/129020107-775d7c94-dca7-4d1f-a0a2-cd63cabf4132.gif)



* 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>
2021-08-19 15:19:06 +00:00
BooksBaum
8a9feeddd3
Remove match_ast usage 2021-08-19 14:17:23 +02:00
BooksBaum
2c27adc0a3
Remove match_ast! macro call
Add node about uncommenting tuple in macro call
2021-08-19 14:09:52 +02:00
bors[bot]
f696fb51c3
Merge #9950
9950: Fix codegen for is_method documentation r=yoshuawuyts a=yoshuawuyts

While authoring https://github.com/rust-lang/rust/pull/88154 I realized that the codegen for the `enum_generate_is_method` assist currently generates invalid paths, and used snake case instead of spaces for the docs description. This fixes both issues. Thanks!

Co-authored-by: Yoshua Wuyts <yoshuawuyts@gmail.com>
2021-08-19 11:31:46 +00:00
Yoshua Wuyts
586d6fca8c Fix codegen for is_method documentation
Previously the generated paths were invalid. This fixes that.
2021-08-19 13:31:16 +02:00
Dawer
08694dc1ef minor: address review comments 2021-08-18 19:04:10 +05:00
Dawer
98847e4d5b internal: use the new edit_in_place::Indent API 2021-08-18 18:08:14 +05:00
bors[bot]
ee4505f396
Merge #9942
9942: fix: Don't trigger related highlighting on unrelated tokens r=Veykril a=Veykril

bors r+

Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
2021-08-18 13:04:53 +00:00
Lukas Wirth
04076bc5fb Don't trigger related highlighting on unrelated tokens 2021-08-18 15:03:39 +02:00
bors[bot]
320bb72b7f
Merge #9941
9941: feat: include full path in the cyclic deps error r=matklad a=matklad

bors r+
🤖

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
2021-08-18 12:36:18 +00:00