Commit Graph

12692 Commits

Author SHA1 Message Date
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
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
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
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
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
Aleksey Kladov
5192ddfa2e feat: include full path in the cyclic deps error 2021-08-18 15:35:04 +03:00
BooksBaum
b1ebb82f32
Add deref (*) handling for usages of ref tuples 2021-08-17 19:23:07 +02:00
BooksBaum
384fae7fcd
Switch order of assists
Destructure in sub-pattern before Destructure in place to favor the
first one
2021-08-17 19:23:06 +02:00
BooksBaum
d0cf28322a
Add generated doctest 2021-08-17 19:23:06 +02:00
BooksBaum
5b9f8e7e8e
Fix errors from rebase master
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.
2021-08-17 19:23:06 +02:00
BooksBaum
b441aa2046
Cleanup according to style-requirements in tests 2021-08-17 19:23:06 +02:00
BooksBaum
45ef57bd23
Fix: different assist ids in doc and code 2021-08-17 19:23:05 +02:00
BooksBaum
0d2490f785
Handle tuple in macro call
Only tuple name is handled (uncommented), not tuple index
2021-08-17 19:23:05 +02:00
BooksBaum
450a9c5b12
Add destructure in sub-pattern (after @) 2021-08-17 19:23:05 +02:00
BooksBaum
3e4051938d
Handle mut & ref 2021-08-17 19:23:04 +02:00
BooksBaum
478b2988c0
Add Destructure Tuple 2021-08-17 19:22:57 +02:00
bors[bot]
d1ba993136
Merge #9936
9936: proc_macro_api: make commit & date suffix of binary version optional r=lnicola a=lnicola

Closes #9916

bors r+

Co-authored-by: Florian sp1rit​ <sp1ritCS@protonmail.com>
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
2021-08-17 16:26:05 +00:00
Laurențiu Nicola
f69225c4fa Fix formatting 2021-08-17 19:25:37 +03:00
Alexander Sieg
778d372900
Bump notify version to 5.0.0-pre.12
Co-authored-by: Laurențiu Nicola <lnicola@users.noreply.github.com>
2021-08-17 17:25:11 +02:00
Alexander Sieg
ca6a1d8c63 Revert "Downgrade notify and use RecommendedWatcher"
This reverts commit 5b0c86af7d.

The pre-5.0.12 release of notify fixed this issue.
2021-08-17 17:17:13 +02:00
bors[bot]
8d7eea9e3a
Merge #9929
9929: fix: Handle all rename special cases for record pattern fields r=Veykril a=Veykril



Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
2021-08-17 13:25:08 +00:00
Lukas Wirth
daf3094958 Emit more concise text edits in ide_db::rename 2021-08-17 15:24:01 +02:00
Florian sp1rit​
2bfaffbf82 proc_macro_api: make commit & date suffix of binary version optional
Signed-off-by: Florian "sp1rit"​ <sp1ritCS@protonmail.com>
2021-08-17 14:08:10 +03:00
Lukas Wirth
995c8f50a2 some code docs for the ide_db/rename module 2021-08-16 23:06:51 +02:00
Lukas Wirth
5e533e5900 Handle all rename special cases for all record pattern fields 2021-08-16 22:48:38 +02:00
bors[bot]
dcbaa75bc1
Merge #9928
9928: internal: Highlight function exit points on `fn` keyword r=Veykril a=Veykril

bors r+

Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
2021-08-16 19:26:18 +00:00
Lukas Wirth
40455db088 Highlight function exit points on fn keyword 2021-08-16 21:25:22 +02:00
Laurențiu Nicola
c9f448a834 Fix some clippy lints 2021-08-16 22:04:26 +03:00
bors[bot]
978b140781
Merge #9921
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>
2021-08-16 16:38:44 +00:00
Lukas Wirth
6523a09562 style 2021-08-16 18:29:16 +02:00
bors[bot]
bae22f9507
Merge #9924
9924: Fix gen debug for enums r=yoshuawuyts a=yoshuawuyts

Closes https://github.com/rust-analyzer/rust-analyzer/issues/9914. Thanks!

r? `@Veykril` 

Co-authored-by: Yoshua Wuyts <yoshuawuyts@gmail.com>
2021-08-16 16:25:57 +00:00
Yoshua Wuyts
067dc660ae implement feedback from review 2021-08-16 18:23:51 +02:00
Lukas Wirth
0336e9b25f Flatten SourceToDefCache structure 2021-08-16 17:55:18 +02:00
Yoshua Wuyts
9374d526da fix debug tuple structs 2021-08-16 17:39:08 +02:00
Lukas Wirth
c90ecc5c26 Only add entries to SourceToDef dynmaps when they come from the same file 2021-08-16 17:07:25 +02:00
bors[bot]
6a07bf6a9f
Merge #9920
9920: minor: Simplify r=Veykril a=Veykril

bors r+

Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
2021-08-16 14:13:04 +00:00
Lukas Wirth
0c0142f61a Simplify 2021-08-16 16:12:20 +02:00
Aleksey Kladov
438d1da6c6 minor: simplify 2021-08-16 14:45:54 +03:00
Aleksey Kladov
d29c52354c minor: remove dead code 2021-08-16 14:28:04 +03:00
Yoshua Wuyts
b67378f53e fix debug record structs 2021-08-16 12:58:06 +02:00