Commit Graph

12731 Commits

Author SHA1 Message Date
Aleksey Kladov
0a7e57177e internal: use single env var to controll all benchmarks 2021-08-23 16:40:42 +03:00
Aleksey Kladov
c044493434 ⬆️ rowan
Just so we don't live on a per-release
2021-08-23 12:10:49 +03:00
bors[bot]
996300f4a0
Merge
9989: Fix two more “a”/“an” typos (this time the other way) r=lnicola a=steffahn

Follow-up to 

you guys are still merging these fast 😅

_this time I thought – for sure – that I’d get this commit into  before it’s merged…_

Co-authored-by: Frank Steffahn <frank.steffahn@stu.uni-kiel.de>
2021-08-22 16:10:48 +00:00
Frank Steffahn
75073451c6 Fix three more (reverse) “a”/“an” typos 2021-08-22 17:48:15 +02:00
Frank Steffahn
5f5d45468d Fix two more “a”/“an” typos (this time the other way) 2021-08-22 17:36:58 +02:00
Florian Diebold
424dda8113 Refactor & improve handling of overloaded binary operators
Fixes . Also records them as method resolutions, which we could use
later.
2021-08-22 17:35:50 +02:00
Frank Steffahn
35a7fdd2c1 Fix two more “a”/“an” typos 2021-08-22 17:24:48 +02:00
bors[bot]
0960d4ebe2
Merge
9937: internal: incentivize rust-analyzed developers to fix panics r=matklad a=matklad



9985: minor: Fix another “a”/“an” typo r=Veykril a=steffahn

Follow-up to .

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
Co-authored-by: Frank Steffahn <frank.steffahn@stu.uni-kiel.de>
2021-08-22 15:01:15 +00:00
Aleksey Kladov
85fbbc5372 internal: incentivize rust-analyzed developers to fix panics
It's good that rust-analyzer doesn't belly-up on a panic in some random
assist.

It is less good that rust-analyzer devs only know that the assists are
buggy when they are actively looking at the logs.
2021-08-22 17:54:50 +03:00
bors[bot]
107b2f1890
Merge
9972: refactor : function generation assists r=Veykril a=mahdi-frms

Separated code generation from finding position for generated code. This will be ground work for introducing static associated function generation.

Co-authored-by: mahdi-frms <mahdif1380@outlook.com>
2021-08-22 14:53:41 +00:00
Frank Steffahn
ab23af439d Fix another “a”/“an” typo 2021-08-22 16:45:58 +02:00
bors[bot]
c6baf3dcf8
Merge
9984: Fix typos “a”→“an” r=Veykril a=steffahn

See 

Co-authored-by: Frank Steffahn <frank.steffahn@stu.uni-kiel.de>
2021-08-22 13:06:34 +00:00
Frank Steffahn
3a5a93595f Fix typos “a”→“an” 2021-08-22 14:31:37 +02:00
bors[bot]
b9d879876e
Merge
9979: fix: Incorrect up-mapping for tokens in derive attributes r=Veykril a=Veykril

Merely detaching the attributes causes incorrect spans to appear when mapping tokens up as the token ids resolve to the ranges of the stripped item so all the text ranges of its tokens are actually lower than the non-stripped ones.

Same fix as with attributes can be applied here, just replace the derive attribute with an equal amount of whitespace.

Fixes 

Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
2021-08-22 12:25:18 +00:00
Lukas Wirth
5507512eaf Replace stripped derives with whitespace in process_macro_input 2021-08-22 14:23:59 +02:00
Aleksey Kladov
e86388689f internal: remove unreasonable crate dependency
Proc macro expansion shouldn't know about salsa at all.
2021-08-22 14:05:12 +03:00
Aleksey Kladov
881d71a489 internal: reduce crate interdependence
I don't think there's anything wrong with project_model depending on
proc_macro_api directly -- fundamentally, both are about gluing our pure
data model to the messy outside world.

However, it's easy enough to avoid the dependency, so why not.

As an additional consideration, `proc_macro_api` now pulls in `base_db`.
project_model should definitely not depend on that!
2021-08-22 13:32:00 +03:00
Aleksey Kladov
5cef007bff internal: improve consistency
load and load_proc_macro do similar things
2021-08-22 13:15:18 +03:00
mahdi-frms
c1edbfbacc better assist label 2021-08-22 12:31:16 +04:30
bors[bot]
8cd171cd94
Merge
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
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: minor: Fix panic caused by  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
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
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
mahdi-frms
1ac9400100 func gen: seperate generation form position(2) 2021-08-21 17:31:37 +04:30
Florian Diebold
1791a35f9f Determine expected parameters from expected return in calls
Fixes 
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: 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 
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: 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
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
Aleksey Kladov
1850849325 internal: prep to 2021 edition 2021-08-20 16:20:18 +03: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
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: 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: feature: Destructure Tuple Assist r=Veykril a=Booksbaum

Part of . 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  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