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

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

Update the docs

Simplify

Refactor the import location

Do not propose already imported imports

Properly handle turbofishes in qualifiers

Fix some tests

Return more data about located imports

Draft the qualifier import resolution

Filter out path items by the qualifier

Simplify

Find the code to change

Test and initial refactoring

Add more documentation for rustc_private

Merge #7924

7924: Use upstream cov-mark r=matklad a=lnicola

Closes #7922

But doesn't remove any dependency, unfortunately.

Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>

Use upstream cov-mark

Merge #7923

7923: Remove useless code_model indirection r=matklad a=matklad

bors r+
🤖

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

Hygiene is an internal implementation detail of the compiler

Remove useless code_model indirection

Merge #7918

7918: Generalize file ensuring infrastructure r=matklad a=matklad

bors r+
🤖

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

Minor

Cleanup the error message

Remove now dead code

Unused params

Make `code generation` just work

Contributors don't need to learn about `cargo xtask codegen` if `cargo
test` just does the right thing.

Use the same name in xtask and test utils

Generalize file ensuring infrastructure

Make working with codegen less annoying

We probably should look into removing `xtask codegen` altogether. The
test workflow works perfectly for package.json config.

There are two things preventing that:

* Lint completions are generated on demand.
* Docs are not committed to the repository.

Merge #7921

7921: Don't punish every crate with serde-json r=matklad a=matklad

bors r+
🤖

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

Don't punish every crate with serde-json

Merge #7891

7891: Improve handling of rustc_private r=matklad a=DJMcNab

This PR changes how `rust-analyzer` handles `rustc_private`. In particular, packages now must opt-in to using `rustc_private` in `Cargo.toml`, by adding:
```toml
[package.metadata.rust-analyzer]
rustc_private=true
```

This means that depending on crates which also use `rustc_private` will be significantly improved, since their dependencies on the `rustc_private` crates will be resolved properly.

A similar approach could be used in #6714 to allow annotating that your package uses the `test` crate, although I have not yet handled that in this PR.

Additionally, we now only index the crates which are transitive dependencies of `rustc_driver` in the `rustcSource` directory. This should not cause any change in behaviour when using `rustcSource: "discover"`, as the source used then will only be a partial clone. However, if `rustcSource` pointing at a local checkout of rustc, this should significantly improve the memory usage and lower indexing time. This is because we avoids indexing all crates in `src/tools/`, which includes `rust-analyzer` itself.

Furthermore, we also prefer named dependencies over dependencies from `rustcSource`. This ensures that feature resolution for crates which are depended on by both `rustc` and your crate uses the correct set for analysing your crate.

See also [introductory zulip stream](https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Fwg-rls-2.2E0/topic/Fixed.20crate.20graphs.20and.20optional.20builtin.20crates/near/229086673)

I have tested this in [priroda](https://github.com/oli-obk/priroda/), and it provides a significant improvement to the development experience (once I give `miri` the required data in `Cargo.toml`)

Todo:
- [ ] Documentation

This is ready to review, and I will add documentation if this would be accepted (or if I get time to do so anyway)

Co-authored-by: Daniel McNab <36049421+DJMcNab@users.noreply.github.com>

Document rustc_private in metadata

Never run cargo check on the rustc source

Only show directory name

Revert "Support disabling rustc build scripts"

This reverts commit ddce6bb282764692d53b719bff4c37e3512d4556.

Merge #7920

7920: Cargo update r=kjeremy a=kjeremy

Chalk changes just a version # bump. There are no actual commits.

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

Cargo update

Chalk changes just a version # bump. There are no actual commits.