6745: ANN: add quick fix to add function parameter from function call r=dima74 a=Kobzol

This PR adds a quick fix that lets the user add new function parameters to a function from a function call, using the new Change signature refactoring. So far it only works for function and method calls and not tuple struct constructors. The behaviour of the fix is heavily inspired by a similar fix in the Kotlin plugin.
![add-parameters](https://user-images.githubusercontent.com/4539057/106059839-964ed400-60f3-11eb-973b-983495cc76fd.gif)

There are two TODOs in the code, which I'm not sure how to resolve:
- How to name parameters? `p0`, `p1`, etc.? Or continue counting from the existing parameter count? Also the fix should probably make sure that it doesn't generate collisions in parameter binding names.
- How to get the correct type reference from the argument expression type? That is especially important for import to work. I tried to use a type reference fragment, that sort-of works, but it imports the type with a wrong path. I need to somehow get from `Ty` to `RsTypeReference` that exists in the context of the target function.

Related issue: #6744
Fixes: #3582

changelog: Add quick fix to add a parameter to a function from a function call.

7229: STUB: stub macro definitions and stub macro calls in code blocks if the block is stubbed  r=vlad20012 a=vlad20012

We need this because `RsItemsOwner.itemsAndMacros` should
behave identically on stubs and on AST. Otherwise, it leads to
weird flaky bugs. This fixes the regression in #7194

Also, macro definitions should be available in symbol search as well as other
items. So they should be stubbed and indexed, even local ones

changelog: FEATURE: Add local macro definitions to `symbol search`. FIX: Fix possible flaky false positives around local macro calls


Co-authored-by: Jakub Beránek <[email protected]>
Co-authored-by: vlad20012 <[email protected]>

7751: GRAM&ANN: parse `unsafe` keyword in modules and annotate it as error r=vlad20012 a=Undin

These changes allow parsing mod items with `unsafe` keyword to be consistent with rustc (see rust-lang/rust#75857) and annotate `unsafe` keyword as an error in such cases on the semantic level.

![image](https://user-images.githubusercontent.com/2539310/131228287-fc3bfcbb-efd2-4f57-9466-a1d196477b3e.png)


Note, the corresponding change in rustc was made mainly to provide token tree to proc macros where `unsafe` keyword should be handled by proc macro itself. And in case of such proc macro, `unsafe` keyword shouldn't be annotated as an error. But after these changes, `unsafe` will be annotated as an error by the plugin. But it doesn't look like a new issue, since previously it was annotated as parser error.

For example, for the following code
```rust
//- lib.rs
use proc_macro::TokenStream;
use std::str::FromStr;

#[proc_macro_attribute]
pub fn my_attr(_attr: TokenStream, _item: TokenStream) -> TokenStream {
    return TokenStream::from_str("pub fn foo() { println!(\"Hello from macro!\")}").unwrap()
}

//- main.rs
#[rust_project::my_attr]
unsafe mod foo {}

fn main() {
    foo();
}
```

the plugin produces the corresponding annotations
| Before | After |
| - | - |
| ![image](https://user-images.githubusercontent.com/2539310/131228207-b9b0ca35-c6dc-4ea3-b91e-0b894cde1d41.png) | ![image](https://user-images.githubusercontent.com/2539310/131228220-4ef37560-ffee-447c-bde1-a87fa4cb44b6.png) |


Proper support for error annotations of such cases should be implemented separately, not only for `unsafe` keyword in modules and requires changes from #7194




changelog: Parse `unsafe` keyword in modules and provide error annotation for it


Co-authored-by: Arseniy Pendryak <[email protected]>

7751: GRAM&ANN: parse `unsafe` keyword in modules and annotate it as error r=vlad20012 a=Undin

These changes allow parsing mod items with `unsafe` keyword to be consistent with rustc (see rust-lang/rust#75857) and annotate `unsafe` keyword as an error in such cases on the semantic level.

![image](https://user-images.githubusercontent.com/2539310/131228287-fc3bfcbb-efd2-4f57-9466-a1d196477b3e.png)


Note, the corresponding change in rustc was made mainly to provide token tree to proc macros where `unsafe` keyword should be handled by proc macro itself. And in case of such proc macro, `unsafe` keyword shouldn't be annotated as an error. But after these changes, `unsafe` will be annotated as an error by the plugin. But it doesn't look like a new issue, since previously it was annotated as parser error.

For example, for the following code
```rust
//- lib.rs
use proc_macro::TokenStream;
use std::str::FromStr;

#[proc_macro_attribute]
pub fn my_attr(_attr: TokenStream, _item: TokenStream) -> TokenStream {
    return TokenStream::from_str("pub fn foo() { println!(\"Hello from macro!\")}").unwrap()
}

//- main.rs
#[rust_project::my_attr]
unsafe mod foo {}

fn main() {
    foo();
}
```

the plugin produces the corresponding annotations
| Before | After |
| - | - |
| ![image](https://user-images.githubusercontent.com/2539310/131228207-b9b0ca35-c6dc-4ea3-b91e-0b894cde1d41.png) | ![image](https://user-images.githubusercontent.com/2539310/131228220-4ef37560-ffee-447c-bde1-a87fa4cb44b6.png) |


Proper support for error annotations of such cases should be implemented separately, not only for `unsafe` keyword in modules and requires changes from #7194




changelog: Parse `unsafe` keyword in modules and provide error annotation for it


Co-authored-by: Arseniy Pendryak <[email protected]>

7751: GRAM&ANN: parse `unsafe` keyword in modules and annotate it as error r=vlad20012 a=Undin

These changes allow parsing mod items with `unsafe` keyword to be consistent with rustc (see rust-lang/rust#75857) and annotate `unsafe` keyword as an error in such cases on the semantic level.

![image](https://user-images.githubusercontent.com/2539310/131228287-fc3bfcbb-efd2-4f57-9466-a1d196477b3e.png)


Note, the corresponding change in rustc was made mainly to provide token tree to proc macros where `unsafe` keyword should be handled by proc macro itself. And in case of such proc macro, `unsafe` keyword shouldn't be annotated as an error. But after these changes, `unsafe` will be annotated as an error by the plugin. But it doesn't look like a new issue, since previously it was annotated as parser error.

For example, for the following code
```rust
//- lib.rs
use proc_macro::TokenStream;
use std::str::FromStr;

#[proc_macro_attribute]
pub fn my_attr(_attr: TokenStream, _item: TokenStream) -> TokenStream {
    return TokenStream::from_str("pub fn foo() { println!(\"Hello from macro!\")}").unwrap()
}

//- main.rs
#[rust_project::my_attr]
unsafe mod foo {}

fn main() {
    foo();
}
```

the plugin produces the corresponding annotations
| Before | After |
| - | - |
| ![image](https://user-images.githubusercontent.com/2539310/131228207-b9b0ca35-c6dc-4ea3-b91e-0b894cde1d41.png) | ![image](https://user-images.githubusercontent.com/2539310/131228220-4ef37560-ffee-447c-bde1-a87fa4cb44b6.png) |


Proper support for error annotations of such cases should be implemented separately, not only for `unsafe` keyword in modules and requires changes from #7194




changelog: Parse `unsafe` keyword in modules and provide error annotation for it


Co-authored-by: Arseniy Pendryak <[email protected]>

7818: PERF: Expand macros in parallel during CrateDefMap building r=vlad20012 a=dima74

Now we expand macros in new resolve using following pipeline:
* Resolve all macros (single thread)
* Expand macros in batches (multithread). Usually [macro cache](#6212) is used here
* Add expanded elements from all macros to DefMap (single thread)

Most performance impact will be on crates with lots of procedural macros (such as [`web-sys`](https://github.com/rustwasm/wasm-bindgen/tree/master/crates/web-sys)) or when we expand macros first time (without cache).

Here is performance comparison on my 8-core machine with code from #7194 (note that currently we use at most 4 processes to expand procedural macros):

project | macro cache? | single-thread | multi-thread | difference
------- | ------------ | ------------- | ------------ | ----------
web-sys |           no |          ~35s |         ~14s |      ~2.5x
web-sys |          yes |        2920ms |       2620ms |       ~10%
cargo   |           no |        3750ms |       3090ms |       ~17%
cargo   |          yes |        1540ms |       1500ms |        ~0%

changelog: Optimize macro expansion — now they are expanded in parallel

7851: Fix `Generate Parser` run configuration r=vlad20012 a=vlad20012

The configuration was broken in #7828 because of TOML plugin source removal

Co-authored-by: Dmitry Murzin <[email protected]>
Co-authored-by: vlad20012 <[email protected]>

7818: PERF: Expand macros in parallel during CrateDefMap building r=vlad20012 a=dima74

Now we expand macros in new resolve using following pipeline:
* Resolve all macros (single thread)
* Expand macros in batches (multithread). Usually [macro cache](#6212) is used here
* Add expanded elements from all macros to DefMap (single thread)

Most performance impact will be on crates with lots of procedural macros (such as [`web-sys`](https://github.com/rustwasm/wasm-bindgen/tree/master/crates/web-sys)) or when we expand macros first time (without cache).

Here is performance comparison on my 8-core machine with code from #7194 (note that currently we use at most 4 processes to expand procedural macros):

project | macro cache? | single-thread | multi-thread | difference
------- | ------------ | ------------- | ------------ | ----------
web-sys |           no |          ~35s |         ~14s |      ~2.5x
web-sys |          yes |        2920ms |       2620ms |       ~10%
cargo   |           no |        3750ms |       3090ms |       ~17%
cargo   |          yes |        1540ms |       1500ms |        ~0%

changelog: Optimize macro expansion — now they are expanded in parallel

Co-authored-by: Dmitry Murzin <[email protected]>

7725: MACRO&RES: support arbitrary items expanded from custom derive r=dima74 a=vlad20012

Depends on #7194

changelog: Take into account all kinds of items generated by custom derive procedural macros. Previously only `impl` blocks were accounted. Please, note that procedural macro expansion is experimental. If you want to try it, enable `org.rust.cargo.evaluate.build.scripts` and `org.rust.macros.proc` experimental features


7908: INT: use Template builder in DestructureIntention and remove RsMultipleVariableRenamer r=dima74 a=Kobzol

`RsMultipleVariableRenamer` was a hack and since the template builder was upgraded, it's no longer needed.

Related: #5650

7959: REF: handle name collisions in RsIntroduceConstantHandler r=dima74 a=Kobzol

This PR adds basic handling of name collisions in `RsIntroduceConstantHandler`.

`@dima74` Is there a better way to get all bindings/names at a given place?

Fixes: #7957

changelog: Handle name collisions in Introduce Constant refactoring.

Co-authored-by: vlad20012 <[email protected]>
Co-authored-by: Jakub Beránek <[email protected]>

6929: ANN: Provide lifetime name check r=mchernyavsky a=Stzx

changelog:

Fixed: #6927


7719: ANN: support E0451 for shorthand struct field literals r=mchernyavsky a=Kobzol

I noticed that E0451 (struct field is private) wasn't being applied for shorthand field literals. This PR fixes it.

changelog: Support the E0451 compiler error for struct field literals using shorthand init.

7725: MACRO&RES: support arbitrary items expanded from custom derive r=dima74 a=vlad20012

Depends on #7194

changelog: Take into account all kinds of items generated by custom derive procedural macros. Previously only `impl` blocks were accounted. Please, note that procedural macro expansion is experimental. If you want to try it, enable `org.rust.cargo.evaluate.build.scripts` and `org.rust.macros.proc` experimental features


Co-authored-by: Stzx <[email protected]>
Co-authored-by: Jakub Beránek <[email protected]>
Co-authored-by: vlad20012 <[email protected]>

7719: ANN: support E0451 for shorthand struct field literals r=mchernyavsky a=Kobzol

I noticed that E0451 (struct field is private) wasn't being applied for shorthand field literals. This PR fixes it.

changelog: Support the E0451 compiler error for struct field literals using shorthand init.

7725: MACRO&RES: support arbitrary items expanded from custom derive r=dima74 a=vlad20012

Depends on #7194

changelog: Take into account all kinds of items generated by custom derive procedural macros. Previously only `impl` blocks were accounted. Please, note that procedural macro expansion is experimental. If you want to try it, enable `org.rust.cargo.evaluate.build.scripts` and `org.rust.macros.proc` experimental features


7770: "Add remaining patterns" quickfix: add patterns even if no `match` body r=mchernyavsky a=t-kameyama

Fixes #7759

```kotlin
enum E { A, B, C }

fn test(e: E, i: i32) {
    match e

    match i

    match {}
}
```

<img width="332" alt="スクリーンショット 2021-09-01 18 59 40" src="https://user-images.githubusercontent.com/1121855/131653263-f8601fb2-5db2-41ea-b876-6ed749d58eb1.png">

↓

<img width="342" alt="スクリーンショット 2021-09-01 19 00 00" src="https://user-images.githubusercontent.com/1121855/131653280-9bfc2eab-6638-46e5-87a6-b865025c47ce.png">


7775: Introduce variable: place new variable in lambda block when target expression is in lambda without braces r=mchernyavsky a=t-kameyama

Fixes #7754

8030: INSP: Add "simplify if with constant condition" inspection r=mchernyavsky a=dima74

We have `RedundantElseInspection` which works for irrefutable patterns and always true `if`-conditions. This PR adds new inspection which works for both always true and always false `if`-conditions. And `RedundantElseInspection` now checks only irrefutable patterns. 

![](https://user-images.githubusercontent.com/6505554/139441929-2b6aea03-1973-47a8-a45c-6f166022a803.gif)

changelog: Add "simplify if with constant condition" inspection


Co-authored-by: Jakub Beránek <[email protected]>
Co-authored-by: vlad20012 <[email protected]>
Co-authored-by: Toshiaki Kameyama <[email protected]>
Co-authored-by: Dmitry Murzin <[email protected]>

7725: MACRO&RES: support arbitrary items expanded from custom derive r=dima74 a=vlad20012

Depends on #7194

changelog: Take into account all kinds of items generated by custom derive procedural macros. Previously only `impl` blocks were accounted. Please, note that procedural macro expansion is experimental. If you want to try it, enable `org.rust.cargo.evaluate.build.scripts` and `org.rust.macros.proc` experimental features


Co-authored-by: vlad20012 <[email protected]>