Merge #7956

7956: Add assist to convert for_each into for loops r=Veykril a=SaiintBrisson

This PR resolves #7821.
Adds an assist to that converts an `Iterator::for_each` into a for loop:

```rust
fn main() {
    let vec = vec![(1, 2), (2, 3), (3, 4)];
    x.iter().for_each(|(x, y)| {
        println!("x: {}, y: {}", x, y);
    })
}
```
becomes
```rust
fn main() {
    let vec = vec![(1, 2), (2, 3), (3, 4)];
    for (x, y) in x.iter() {
        println!("x: {}, y: {}", x, y);
    });
}
```

Co-authored-by: Luiz Carlos Mourão Paes de Carvalho <luizcarlosmpc@gmail.com>
Co-authored-by: Luiz Carlos <luizcarlosmpc@gmail.com>
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>

Fix convert_iter_for_each_to_for doctest

Merge #7904

7904: Improved completion sorting r=JoshMcguigan a=JoshMcguigan

I was working on extending #3954 to apply completion scores in more places (I'll have another PR open for that soon) when I discovered that actually completion sorting was not working for me at all in `coc.nvim`. This led me down a bit of a rabbit hole of how coc and vs code each sort completion items.

Before this PR, rust-analyzer was setting the `sortText` field on completion items to `None` if we hadn't applied any completion score for that item, or to the label of the item with a leading whitespace character if we had applied any completion score. Completion score is defined in rust-analyzer as an enum with two variants, `TypeMatch` and `TypeAndNameMatch`.

In vs code the above strategy works, because if `sortText` isn't set [they default it to the label](https://github.com/microsoft/vscode/commit/b4ead4ed665e1ce2e58d8329c682f78da2d4e89d). However, coc [does not do this](https://github.com/neoclide/coc.nvim/blob/e211e361475a38b146a903b9b02343551c6cd372/src/completion/complete.ts#L245).

I was going to file a bug report against coc, but I read the [LSP spec for the `sortText` field](https://microsoft.github.io/language-server-protocol/specifications/specification-current/#textDocument_completion) and I feel like it is ambiguous and coc could claim what they do is a valid interpretation of the spec.

Further, the existing rust-analyzer behavior of prepending a leading whitespace character for completion items with any completion score does not handle sorting `TypeAndNameMatch` completions above `TypeMatch` completions. They were both being treated the same.

The first change this PR makes is to set the `sortText` field to either "1" for `TypeAndNameMatch` completions, "2" for `TypeMatch` completions, or "3" for completions which are neither of those. This change works around the potential ambiguity in the LSP spec and fixes completion sorting for users of coc. It also allows `TypeAndNameMatch` items to be sorted above just `TypeMatch` items (of course both of these will be sorted above completion items without a score).

The second change this PR makes is to use the actual completion scores for ref matches. The existing code ignored the actual score and always assumed these would be a high priority completion item.

#### Before

Here coc just sorts based on how close the items are in the file.


#### After

Here we correctly get `zzz` first, since that is both a type and name match. Then we get `ccc` which is just a type match.


Co-authored-by: Josh Mcguigan <joshmcg88@gmail.com>

update relevance score u8 -> u32

add relevance score test

remove unused CompletionScore enum

add completion relevance score

Merge #7980

7980: Fix remaining references to `cargo xtask codegen` r=matklad a=Veykril

Co-authored-by: Lukas Wirth <lukastw97@gmail.com>

Fix remaining references to `cargo xtask codegen`

fix: generated test fixture

fix: replace doc-comments with normal comments

Co-authored-by: Lukas Wirth <lukastw97@gmail.com>

refactor: refactored and reduced assist code

Merge #7978

7978: Unify naming r=matklad a=matklad

bors r+
🤖

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>

Unify naming

Merge #7974

7974: use references in CompletionItem's builder r=matklad a=yonip23

@matklad
This is a follow up to [this pr](https://github.com/rust-analyzer/rust-analyzer/pull/7973)

Co-authored-by: yonip23 <yoni@codota.com>

use references in CompletionItem's builder

Merge #7972

7972: fix: add semicolon after type ascription r=matklad a=conradludgate

Fixes #7971

Co-authored-by: Conrad Ludgate <conradludgate@gmail.com>

fix: add semicolon after type ascription

Merge #7969

7969: Return original text range in PrepareRename responses when inside macro r=Veykril a=Veykril

bors r+
Issue found in #7968

Co-authored-by: Lukas Wirth <lukastw97@gmail.com>

Return original text range in PrepareRename responses when inside macro

Merge #7967

7967: Use expect-test for builtin macro/derive tests r=jonas-schievink a=jonas-schievink

bors r+

Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>

Use expect-test for builtin macro/derive tests

Merge #7965

7965: cargo update and lexer r=kjeremy a=kjeremy

Co-authored-by: kjeremy <kjeremy@gmail.com>

cargo update and lexer

Merge #7964

7964: Implement builtin `cfg!` macro r=jonas-schievink a=jonas-schievink

bors r+

Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>

fix: remove semicolon

Implement builtin `cfg!` macro

Merge #7961

7961: add user docs for ssr assist r=JoshMcguigan a=JoshMcguigan

@matklad

This is a small follow up on #7874, adding user docs for the SSR assist functionality. Since most other assists aren't handled this way I wasn't sure exactly how we wanted to document this, so feel free to suggest alternatives.

Co-authored-by: Josh Mcguigan <joshmcg88@gmail.com>

add user docs for ssr assist

Merge #7959

7959: Prefer names from outer DefMap over extern prelude r=jonas-schievink a=jonas-schievink

Fixes https://github.com/rust-analyzer/rust-analyzer/issues/7919

Just one more special case, how bad could it be.

bors r+

Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>

Prefer names from outer DefMap over extern prelude

Merge #7958

7958: Avoid double text edits when renaming mod declaration r=matklad a=Veykril

Closes https://github.com/rust-analyzer/rust-analyzer/issues/7916

See https://github.com/microsoft/vscode-languageserver-node/issues/752 for context

Co-authored-by: Lukas Wirth <lukastw97@gmail.com>

Avoid double text edits when renaming mod declaration

Merge #7874

7874: add apply ssr assist r=JoshMcguigan a=JoshMcguigan

This PR adds an `Apply SSR` assist which was briefly mentioned in #3186. It allows writing an ssr rule as a comment, and then applying that SSR via an assist. This workflow is much nicer than the default available via `coc-rust-analyzer` when iterating to find the proper replacement.

As currently implemented, this requires the ssr rule is written as a single line in the comment, and it doesn't require any kind of prefix. Anything which properly parses as a ssr rule will enable the assist. The benefit of requiring the ssr rule be on a single line is it allows for a workflow where the user has several rules written one after the other, possibly to be triggered in order, without having to try to parse multiple lines of text and determine where one rule ends and the next begins. The benefit of not requiring a prefix is less typing :laughing:  - plus, I think the chance of something accidentally parsing as an ssr rule is minimal.

I think a reasonable extension of this would be to allow either any ssr rule that fits on a single line, or any comment block which in its entirety makes up a single ssr rule (parsing a comment block containing multiple ssr rules and running them all would break the use case that currently works where a user writes multiple ssr rules then runs them each one by one in arbitrary order).

I've marked this as a draft because for some reason I am strugging to make the unit tests pass. It does work when I compile rust-analyzer and test it in my editor though, so I'm not sure what is going on.

Co-authored-by: Josh Mcguigan <joshmcg88@gmail.com>

add apply ssr assist

Merge #7957

7957: Fix labels for single import assists r=SomeoneToIgnore a=SomeoneToIgnore

Before:

After:

Co-authored-by: Kirill Bulatov <mail4score@gmail.com>

Fix labels for single import assists

fix: code formatting

fix:  tests should work for convert_iter_for_each_to_for

refactor: create block expressions and for loops using make

feat: add expr_for_loop to make in syntax

feat: add assist to conver for_each into for loops

Merge #7955

7955: Stop fetching ItemTrees for no reason r=jonas-schievink a=jonas-schievink

bors r+

Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>

Stop fetching ItemTrees for no reason

Merge #6822

6822: Read version of rustc that compiled proc macro r=edwin0cheng a=jsomedon

Signed-off-by: Jay Somedon <jay.somedon@outlook.com>
This PR is to fix #6174.

I basically
* added two methods, `read_version` and `read_section`(used by `read_version`)
* two new crates `snap` and `object` to be used by those two methods

I just noticed that some part of code were auto-reformatted by rust-analyzer on file save. Does it matter?

Co-authored-by: Jay Somedon <jay.somedon@outlook.com>
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>

use doc-comments

Merge #7949

7949: Compilation speed r=matklad a=matklad

bors r+
🤖

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>

Compilation speed

Merge #7948

7948: Delete `ContainerId` r=jonas-schievink a=jonas-schievink

Since block expressions containing items now have a `ModuleId`, there's no need to also treat `DefWithBodyId` as a potential item container. Since https://github.com/rust-analyzer/rust-analyzer/pull/7878, only the `ModuleId` variant of `ContainerId` was ever created, so just delete the thing and use `ModuleId` everywhere.

bors r+

Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>

Delete `ContainerId`

Merge #7878

7878: Remove `item_scope` field from `Body` r=jonas-schievink a=jonas-schievink

Closes https://github.com/rust-analyzer/rust-analyzer/issues/7632

Instead of storing an `ItemScope` filled with inner items, we store the list of `BlockId`s for all block expressions that are part of a `Body`. Code can then query the `block_def_map` for those.

bors r+

Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>

Stop using `ContainerId` in `AssocContainerId`

Check ancestor maps when computing traits in scope

Remove `item_scope` field from `Body`

Use `body.block_scopes` in `hir_ty` tests

Use `body.block_scopes` to validate inner items

Use `body.block_scopes` in `ChildBySource`

Store inner `BlockId`s in `Body`

Change `ChildBySource` to allow reusing `DynMap`

Merge #7945

7945: Future proof completion scores r=matklad a=matklad

bors r+
🤖

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>

Future proof completion scores

Merge #7942

7942: Show whether a binding is mutable or not on hover r=Veykril a=Veykril

bors r+

Co-authored-by: Lukas Wirth <lukastw97@gmail.com>

Show whether a binding is mutable or not on hover

Merge #7944

7944: Selecting `&mut foo` completion now actually inserts `&mut` r=matklad a=matklad

bors r+
🤖

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>

Selecting `&mut foo` completion now actually inserts `&mut`

Don't show const items initializer expressions on hover

Cleanup auto-ref in completion

Merge #7941

7941: Fix unused definitions not being document highlit r=Veykril a=Veykril

Fixes #7939

bors r+

Co-authored-by: Lukas Wirth <lukastw97@gmail.com>

Merge #7940

7940: Cleanup r=matklad a=matklad

bors r+
🤖

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>

Fix unused definitions not being document highlit

Cleanup

Cleanup

Fix bad names

`res` should only be used for the result variable

Merge #7873 #7933

7873: Consider unresolved qualifiers during flyimport r=matklad a=SomeoneToIgnore

Closes https://github.com/rust-analyzer/rust-analyzer/issues/7679

Takes unresolved qualifiers into account, providing better completions (or none, if the path is resolved or do not match).

Does not handle cases when both path qualifier and some trait has to be imported: there are many extra issues with those (such as overlapping imports, for instance) that will require large diffs to address.

Also does not do a fuzzy search on qualifier, that requires some adjustments in `import_map` for better queries and changes to the default replace range which also seems relatively big to include here.


7933: Improve compilation speed r=matklad a=matklad

bors r+
🤖

Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>

Improve compilation speed

Merge #7932

7932: Make code less surprising r=matklad a=matklad

bors r+
🤖

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>

Make code less surprising

Theres no reason to have literal `\n\n` in the source code

Merge #7931

7931: Use `Type::new_with_resolver_inner` more r=jonas-schievink a=jonas-schievink

bors r+

Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>

Use `Type::new_with_resolver_inner` more

Merge #7927

7927: Add more documentation for rustc_private r=matklad a=jyn514

Co-authored-by: Joshua Nelson <jyn514@gmail.com>

Merge #7928

7928: Add completion to turn x.err into Err(x) r=matklad a=duongdominhchau

PR for issue #7925

Co-authored-by: Duong Do Minh Chau <duongdominhchau@gmail.com>

Fix format

Merge #7930

7930: Clarify that all caps are experimental r=matklad a=matklad

bors r+
🤖

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>

Clarify that all caps are experimental

Add trailing commas

Update the test to match the change

Add completion to turn x.err into Err(x)

Merge #7898

7898: generate_function assist: infer return type r=JoshMcguigan a=JoshMcguigan

This PR makes two changes to the generate function assist:

1. Attempt to infer an appropriate return type for the generated function
2. If a return type is inferred, and that return type is not unit, don't render the snippet

```rust
fn main() {
    let x: u32 = foo$0();
    //              ^^^ trigger the assist to generate this function
}

// BEFORE
fn foo() ${0:-> ()} {
    todo!()
}

// AFTER (only change 1)
fn foo() ${0:-> u32} {
    todo!()
}

// AFTER (change  1 and 2, note the lack of snippet around the return type)
fn foo() -> u32 {
    todo!()
}
```

These changes are made as two commits, in case we want to omit change 2. I personally feel like it is a nice change, but I could understand there being some opposition.

#### Pros of change 2
If we are able to infer a return type, and especially if that return type is not the unit type, the return type is almost as likely to be correct as the argument names/types. I think this becomes even more true as people learn how this feature works.

#### Cons of change 2

We could never be as confident about the return type as we are about the function argument types, so it is more likely a user will want to change that. Plus it is a confusing UX to sometimes have the cursor highlight the return type after triggering this assist and sometimes not have that happen.

#### Why omit unit type?

The assumption is that if we infer the return type as unit, it is likely just because of the current structure of the code rather than that actually being the desired return type. However, this is obviously just a heuristic and will sometimes be wrong. But being wrong here just means falling back to the exact behavior that existed before this PR.

Co-authored-by: Josh Mcguigan <joshmcg88@gmail.com>

generate_function assist don't render snippet if ret type inferred

Better strip turbofishes

Add rustdocs and use better names

Less lifetines: derive SemanticsScope in place

Rebase leftovers

Cleanup

Restrict fuzzy qualifiers for now

Test for fuzzy unresolved path maatch

Enforce the located imports' order

Fix the completion labels and tests

Work towards better import labels

Profile import_assets better