fix: resolve all inference vars in `InferenceResult::assoc_resolutions`

Auto merge of #13746 - feniljain:fix_extract_function, r=jonas-schievink

fix: make make_body respect comments in extract_function

Possible fix for #13621

### Points to help in review:

- Earlier we were only considering statements in a block expr and hence comments were being ignored, now we handle tokens hence making it aware of comments and then preserving them using `hacky_block_expr_with_comments`

Seems like I am not able to attach output video, github is glitching for it :(

Auto merge of #13715 - feniljain:fix_completions, r=jonas-schievink

fix: breaking snippets on typed incomplete suggestions

Possible fix for #7929

Fix the case where if a user types `&&42.o`, snippet completion was still applying &&Ok(42). Note this was fixed previously on `&&42.` but this still remained a problem for this case

Previous relevant PR: #13517

### Points to help in review:

- The main problem why everything broke on adding an extra `o` was, earlier `dot_receiver` was `42.` which was a `LITERAL` but now `42.o` becomes a `FIELD_EXPR`

- Till now `include_references` was just checking for parent of `LITERAL` and if it was a `REF_EXPR`, but now we consider `FIELD_EXPR` and traverse all of them, finally to reach `REF_EXPR`. If `REF_EXPR` is not found we  just return the original `initial_element`

- We are constructing a new node during `include_references` because if we rely on `dot_receiver` solely we would get `&&42.o` to be replaced with, but we want `&&42` to be replaced with

### Output Video:

https://user-images.githubusercontent.com/49019259/205420166-efbdef78-5b3a-4aef-ab4b-d892dac056a0.mov

Hope everything I wrote makes sense 😅

Also interestingly previous PR's number was `13517` and this PR's number is `13715`, nicee

Auto merge of #13726 - feniljain:fix_assists, r=jonas-schievink

feat: allow unwrap block in let initializers

Possible fix for #13679

### Points to help in review:

- I just added a parent case for let statements and it seems everything else was in place already, so turned out to be a small fix

Auto merge of #13732 - rami3l:fix/gen-partial-eq, r=jonas-schievink

fix: add fallback case in generated `PartialEq` impl

Partially fixes #13727.

When generating `PartialEq` implementations for enums, the original code can already generate the following fallback case:

```rs
_ => std::mem::discriminant(self) == std::mem::discriminant(other),
```

However, it has been suppressed in the following example for no good reason:

```rs
enum Either<T, U> {
    Left(T),
    Right(U),
}

impl<T, U> PartialEq for Either<T, U> {
    fn eq(&self, other: &Self) -> bool {
        match (self, other) {
            (Self::Left(l0), Self::Left(r0)) => l0 == r0,
            (Self::Right(l0), Self::Right(r0)) => l0 == r0,
            // _ => std::mem::discriminant(self) == std::mem::discriminant(other),
            // ^ this completes the match arms!
        }
    }
}
```

This PR has removed that suppression logic.

~~Of course, the PR could have suppressed the fallback case generation for single-variant enums instead, but I believe that this case is quite rare and should be caught by `#[warn(unreachable_patterns)]` anyway.~~

After this fix, when the enum has >1 variants, the following fallback arm will be generated :

* `_ => false,` if we've already gone through every case where the variants of `self` and `other` match;
* The original one (as stated above) in other cases.

---

Note: The code example is still wrong after the fix due to incorrect trait bounds.

Auto merge of #13762 - jonas-schievink:underscore-expr-first, r=jonas-schievink

fix: Fix parsing of `_ = x` in closure body

Fixes https://github.com/rust-lang/rust-analyzer/issues/13757

Fix parsing of `_ = x` in closure body

Auto merge of #13756 - flodiebold:simplify-assoc-item-subst, r=flodiebold

Make assoc_resolutions always have a Substitution

Make assoc_resolutions always have a Substitution

Auto merge of #13725 - bvanjoi:resolve-const-triat-impls, r=flodiebold

feat: resolve const for trait impls

Fixed #13694

feat: resolve const for trait impls(close #13694)

Auto merge of #13750 - lowr:fix/rpit-in-projection, r=flodiebold

fix: normalize projection after discarding free `BoundVar`s in RPIT

Fixes #13307

When we lower the return type of a function, it may contain free `BoundVar`s in `OpaqueType`'s substitution, which would cause panic during canonicalization as part of projection normalization. Those `BoundVar`s are irrelevant in this context and will be discarded, and we should defer projection normalization until then.

Auto merge of #13742 - lowr:fix/assoc-type-shorthand-with-gats, r=flodiebold

fix: only shift `BoundVar`s that come from outside lowering context

Fixes #13734

There are some free functions `TyLoweringContext` methods call, which do not know anything about current binders in scope. We need to shift in the `BoundVar`s in substitutions that we get from them (#4952), but not those we get from `TyLoweringContext` methods.

Auto merge of #13749 - WaffleLapkin:remove_some_redudant_adjustment_hints, r=Veykril

fix: Don't show duplicated adjustment hints for blocks, ifs and matches

Before:
After:

----

I want to improve adjustment hints, this is the first step :)

fix: normalize projection after discarding free `BoundVar`s in RPIT

fix: Don't show duplicated adjustment hints for blocks, ifs and matches

Auto merge of #13745 - Veykril:ty-hint-variant-field, r=Veykril

Show type info on hover of enum variant fields

Small addition to https://github.com/rust-lang/rust-analyzer/pull/13490

fix: make make_body respect comments in extract_function

Auto merge of #13733 - WaffleLapkin:remove_parens, r=Veykril

feat: Add "Remove redundant parentheses" assist


Can be quite handy when refactoring :)

Auto merge of #13722 - MariaSolOs:add-json-contrib, r=Veykril

Add VS Code schema validation for `rust-project.json`

Now that https://github.com/SchemaStore/schemastore/pull/2628 has been merged, adding the `jsonValidation` contribution to the VS Code extension for better editor support when modifying `rust-project.json` files.

Related issue: #13714

Show type info on hover of enum variant fields

Simplify `remove_parentheses`'s implementation

Move precedence handling to `crates/syntax`

Explicitly say that the assist removes *redundant* parentheses

Only shift `BoundVar`s that come from outside `TyLoweringContext`

Disallow access to free `BoundVar`s outside `TyLoweringContext`

Auto merge of #13490 - HKalbasi:layout, r=jonas-schievink

Compute data layout of types

cc #4091

Things that aren't working:
* Closures
* Generators (so no support for `Future` I think)
* Opaque types
* Type alias and associated types which may need normalization

Things that show wrong result:
* ~Enums with explicit discriminant~
* SIMD types
* ~`NonZero*` and similar standard library items which control layout with special attributes~

At the user level, I didn't put much work, since I wasn't confident about what is the best way to present this information. Currently it shows size and align for ADTs, and size, align, offset for struct fields, in the hover, similar to clangd. I used it some days and I feel I liked it, but we may consider it too noisy and move it to an assist or command.

fix: refine fallback case in generated `PartialEq` impl

Add a fixme comment in current_target_data_layout

use rustc crates instead of copy paste

Consider expression precedense in `remove_parentheses` assist

Add `remove_parentheses` assist

fix: add fallback case in generated `PartialEq` impl

Auto merge of #13730 - lowr:feat/builtin-macro-helper-attr, r=Veykril

Support builtin derive macro helper attributes

Closes #13244

It's a bit wasteful for `Macro2Data` to have `helpers` field currently just for `Default` derive macro, but I tend to think it's okay for the time being given how rare macro2's are used.

Resolve macro2's derive helpers in IDE layer

Macro2's generally don't have derive helpers, but currently builtin
derive macros are declared with macro2 syntax, which can have derive
helpers.

Parse and collect derive helpers for builtin derive macros

Auto merge of #13728 - detrumi:chalk-update, r=lnicola

Update to Chalk 88

This Chalk release introduces fuel for the recursive solver ([chalk#774](https://github.com/rust-lang/chalk/pull/774)).
I'm not sure how often it calls `should_continue` compared to the other solver, so we might want to increase `CHALK_SOLVER_FUEL`, the current default value of 100 might be too low.

This should fix a lot of hangs and crashes, for example this solves the hang in #12897.

Increase Chalk fuel from 100 to 1000

The old value was for the old chalk-engine solver, nowadays the newer chalk-recursive solver is used.
The new solver currently uses fuel a bit more quickly, so a higher value is needed.
Running analysis-stats showed that a value of 100 increases the amount of unknown types,
while for a value of 1000 it's staying mostly the same.

Update to Chalk 88

feat: allow unwrap block in let initializers

Add JSON schema contribution

Auto merge of #13721 - Veykril:incoherent-impls, r=Veykril

Support `rustc_has_incoherent_inherent_impls`

Fixes us not resolving `<dyn Error>::downcast` now that `Error` moved to core, while that assoc function is declared in `alloc`.

Support `rustc_has_incoherent_inherent_impls`

support nonzero* niche optimizations

Compute data layout of types

Auto merge of #13717 - lowr:fix/proc-macro-ident-is-raw, r=Veykril

Handle raw identifiers in proc macro server

Fixes #13706

When proc macros create `proc_macro::Ident`s, they pass an identifier text without "r#" prefix and a flag `is_raw` to proc macro server. Our `tt::Ident` currently stores the text *with* "r#" so we need to adjust them somewhere.

Rather than following rustc and adding `is_raw` field to our `tt::Ident`, I opted for adjusting the representation of identifiers in proc macro server, because we don't need the field outside it.

It's hard to write regression test for this, but at least I:
- ran `cargo +nightly t --features sysroot-abi` and all the tests passed
- built proc macro server with `cargo +nightly b -r --bin rust-analyzer-proc-macro-srv --features sysroot-abi` and made sure #13706 resolved
  - For the record, the nightly versions used are `rustc 1.67.0-nightly (32e613bba 2022-12-02)` and `cargo 1.67.0-nightly (e027c4b5d 2022-11-25)`.

Handle raw identifiers in proc macro server

Auto merge of #13707 - lowr:feat/move-const-to-impl, r=Veykril

Add `move_const_to_impl` assist

Closes #13277

For the initial implementation, this assist:
- only applies to inherent impl. Much as we can *technically* provide this assist for default impl in trait definitions, it'd be complicated to get it right.
- may break code when the const's name collides with an item of a trait the self type implements.

Comments in the code explain those caveats in a bit more detail.

Auto merge of #13713 - allanbrondum:bug/trait-method-callers, r=Veykril

check reference is a NameRef (and not Name)

Fixes that implementing methods are shown in call hierarchy https://github.com/rust-lang/rust-analyzer/issues/13712

fix: breaking snippets on typed incomplete suggestions

Fix the case where if a user types `&&42.o`, snippet completion
was still applying &&Ok(42). Note this was fixed previously
on `&&42.` but this still remained a problem for this case

fmt

remove unneeded test

check reference is a NameRef (and not Name)

Add `move_const_to_impl` assist

Auto merge of #13697 - jonas-schievink:version-inlay-hint-resolve-data, r=jonas-schievink

internal: Version the inlay hint resolve data

cc https://github.com/rust-lang/rust-analyzer/issues/13657
cc https://github.com/rust-lang/rust-analyzer/issues/13372
cc https://github.com/rust-lang/rust-analyzer/issues/13170

This will make us log an error and return the unmodified inlay hints when the client attempts to resolve inlay hints in a file that has since been modified.

Update hash

Version the inlay hint resolve data

Auto merge of #13696 - jonas-schievink:signature-help-between-closing-delims, r=jonas-schievink

fix: Fix signature help not showing up when cursor is between `))` or `>>`

Fixes https://github.com/rust-lang/rust-analyzer/issues/13672

Fix signature help not showing up when cursor is between `))` or `>>`

Auto merge of #13695 - detrumi:chalk-update, r=Veykril

Update Chalk to version 87

Changes:
- Support new `tuple_trait` lang item ([chalk#782](https://github.com/rust-lang/chalk/pull/782))
- Removed empty lifetime ([chalk#783](https://github.com/rust-lang/chalk/pull/783))

Update Chalk to version 87

Auto merge of #13690 - Crauzer:vararg-type, r=Veykril

feat: Implement vararg parameter type inference

This PR implements the "collection" of the `va_list` type into the function parameter types list.

Auto merge of #13686 - MariaSolOs:test-lenses, r=Veykril

Don't show runnable code lenses in libraries outside of the workspace

Addresses #13664. For now I'm just disabling runnable code lenses since the ones that display the number of references and implementations do work correctly with external code.

Also made a tiny TypeScript change to use the typed `sendNotification` overload.

Fix formatting

implement vararg type collection from function params

Check for workspace root in runnable codelens

Use typed notification method

Auto merge of #13681 - lowr:fix/extract-function-tail-expr, r=Veykril

fix: check tail expressions more precisely in `extract_function`

Fixes #13620

When extracting expressions with control flows into a function, we can avoid wrapping tail expressions in `Option` or `Result` when they are also tail expressions of the container we're extracting from (see #7840, #9773). This is controlled by `ContainerInfo::is_in_tail`, but we've been computing it by checking if the tail expression of the range to extract is contained in the container's syntactically last expression, which may be a block that contains both tail and non-tail expressions (e.g. in #13620, the range to be extracted is not a tail expression but we set the flag to true).

This PR tries to compute the flag as precise as possible by utilizing `for_each_tail_expr()` (and also moves the flag to `Function` struct as it's more of a property of the function to be extracted than of the container).

Auto merge of #13611 - yue4u:fix/completion-after-colon, r=yue4u

fix: filter unnecessary completions after colon

close #13597
related: #10173

This PR also happens to fix two extra issues:

1. The test case in https://github.com/rust-lang/rust-analyzer/blob/master/crates/ide-completion/src/tests/attribute.rs#L778-L801 was never triggered in previous behavior.

after:

https://user-images.githubusercontent.com/26110087/201476995-56adf955-0fa7-4f75-ab32-28a8e6cb9504.mp4

<del>
2. completions were triggered even in invalid paths, like

```rust
fn main() {
    core:::::$0
}
```

```rust
#[:::::$0]
struct X;
```

</del>

only `:::` is excluded as discussed in https://github.com/rust-lang/rust-analyzer/pull/13611#discussion_r1031845205

fix: also exclude 2 coloncolon in a row

fix: only special casing 3 colon in a row

fix: check if range contains tail expression

refactor: remove unnecessary stuff

Auto merge of #13678 - Veykril:hir-file-encode, r=Veykril

Encode the variants of `HirFileId` in a u32 with MSB as the tag

This saves 10mb on `self` analysis, while this does limit us to 2billion real files and 2 billion macro expansions, I doubt we will ever hit that limit :) `HirFileId` is used a lot, so going from 8 bytes to 4 is a decent win.

Encode the variants of `HirFileId` in a u32 with MSB as the tag

Auto merge of #13676 - fasterthanlime:subtree-fix, r=Veykril

Mega-sync from `rust-lang/rust`

This essentially implements `@oli-obk's` suggestion here https://github.com/rust-lang/rust-analyzer/pull/13459#issuecomment-1297285607, with `@eddyb's` help.

This PR is equivalent to 14 syncs (back and forth) between `rust-lang/rust` and `rust-lang/rust-analyzer`.

Working from this list (from bottom to top):

```
(x) a2a1d9954 :arrow_up: rust-analyzer
(x) 79923c382 :arrow_up: rust-analyzer
(x) c60b1f641 :arrow_up: rust-analyzer
(x) 8807fc4cc :arrow_up: rust-analyzer
(x) a99a48e78 :arrow_up: rust-analyzer
(x) 4f55ebbd4 :arrow_up: rust-analyzer
(x) f5fde4df4 :arrow_up: rust-analyzer
(x) 459bbb422 :arrow_up: rust-analyzer
(x) 65e1dc4d9 :arrow_up: rust-analyzer
(x) 3e358a682 :arrow_up: rust-analyzer
(x) 31519bb39 :arrow_up: rust-analyzer
(x) 8231fee46 :arrow_up: rust-analyzer
(x) 22c8c9c40 :arrow_up: rust-analyzer
(x) 9d2cb42a4 :arrow_up: rust-analyzer
```

(This listed was assembled by doing a `git subtree push`, which made a branch, and looking at the new commits in that branch, picking only those that were `:arrow_up: rust-analyzer` commits)

We used the following commands to simulate merges in both directions:

```shell
TO_MERGE=22c8c9c40 # taken from the list above, bottom to top
git merge --no-edit --no-ff $TO_MERGE
git merge --no-edit --no-ff $(git -C ../rust log --pretty=format:'%cN | %s | %ad => %P' | rg -m1 -F "$(git show --no-patch --pretty=format:%ad $TO_MERGE)" | tee /dev/stderr | rg '.* => \S+ (\S+)$' --replace '$1')
```

We encountered no merge conflicts that Git wasn't able to solve by doing it this way.

Here's what the commit graph looks like (as shown in the Git Lens VSCode extension):

<img width="1345" alt="image" src="https://user-images.githubusercontent.com/7998310/203984523-7c1a690a-8224-416c-8015-ed6e49667066.png">

This PR closes #13459

## Does this unbreak `rust->ra` syncs?

Yes, here's how we tried:

In `rust-analyzer`:

  * check out `subtree-fix` (this PR's branch)
  * make a new branch off of it: `git checkout -b subtree-fix-merge-test`
  * simulate this PR getting merged with `git merge master`

In `rust`:

  * pull latest master
  * make a new branch: `git checkout -b test-change`
  * mess with rust-analyzer (I added a comment to `src/tools/rust-analyzer/Cargo.toml`)
  * commit
  * run `git subtree push -P src/tools/rust-analyzer ra-local final-sync` (this follows the [Clippy sync guide](https://doc.rust-lang.org/nightly/clippy/development/infrastructure/sync.html))

This created a `final-sync` branch in `rust-analyzer`.

In `rust-analyzer`:

  * `git merge --no-ff final-sync` (this follows the [Clippy sync guide](https://doc.rust-lang.org/nightly/clippy/development/infrastructure/sync.html))

Now `git log` in `rust-analyzer` shows this:

```
commit 460128387e46ddfc2b95921b2d7f6e913a3d2b9f (HEAD -> subtree-fix-merge-test)
Merge: 0513fc02a 9ce6a734f
Author: Amos Wenger <amoswenger@gmail.com>
Date:   Fri Nov 25 13:28:24 2022 +0100

    Merge branch 'final-sync' into subtree-fix-merge-test

commit 0513fc02a08ea9de952983624bd0a00e98044b36
Merge: 38c98d1ff 6918009fe
Author: Amos Wenger <amoswenger@gmail.com>
Date:   Fri Nov 25 13:28:02 2022 +0100

    Merge branch 'master' into subtree-fix-merge-test

commit 9ce6a734f37ef8e53689f1c6f427a9efafe846bd (final-sync)
Author: Amos Wenger <amoswenger@gmail.com>
Date:   Fri Nov 25 13:26:26 2022 +0100

    Mess with rust-analyzer just for fun
```

And `git diff 0513fc02a08ea9de952983624bd0a00e98044b36` shows this:

```patch
diff --git a/Cargo.toml b/Cargo.toml
index 286ef1e7d..c9e24cd19 100644
--- a/Cargo.toml
+++ b/Cargo.toml
`@@` -32,3 +32,5 `@@` debug = 0
 # ungrammar = { path = "../ungrammar" }

 # salsa = { path = "../salsa" }
+
+# lol, hi
```

## Does this unbreak `ra->rust` syncs?

Yes, here's how we tried.

From `rust`:

  * `git checkout -b sync-from-ra`
  * `git subtree pull -P src/tools/rust-analyzer ra-local subtree-fix-merge-test` (this is adapted from the [Clippy sync guide](https://doc.rust-lang.org/nightly/clippy/development/infrastructure/sync.html#performing-the-sync-from-clippy-to-rust-langrust), you would normally use `ra-upstream master` but we're simulating things here)

A commit editor pops up, there was no merge conflicts.

## How do we prevent this from happening again?

Like `@bjorn3` said in https://github.com/rust-lang/rust-analyzer/pull/13459#issuecomment-1293587848

> Whenever syncing from rust-analyzer -> rust you have to immediately sync the merge commit from rust -> rust-analyzer to prevent merge conflicts in the future.

But if we get it wrong again, at least now we have a not-so-painful way to fix it.

Merge commit '26562973b3482a635416b2b663a13016d4d90e20' into HEAD

Merge commit 'a2a1d9954' into HEAD

Merge commit 'd03c1c87d4ca2d524646316387d47b12524ac451' into HEAD

Merge commit '79923c382' into HEAD

Merge commit 'ba28e19b7838e3ad4223ae82d074dc3950ef1548' into HEAD

Merge commit 'c60b1f641' into HEAD

Merge commit '43fb9563b2943d6abc5f3552195f3e27ac618966' into HEAD

Merge commit '8807fc4cc' into HEAD

Merge commit '0531aab522f25d6aae30b2cc23a09f4b9257eedc' into HEAD

Merge commit 'a99a48e78' into HEAD

Merge commit '61504c8d951c566eb03037dcb300c96f4bd9a8b6' into HEAD

Merge commit '4f55ebbd4' into HEAD

Merge commit '187bee0bb100111466a3557c20f80defcc0f4db3' into HEAD

Merge commit 'f5fde4df4' into HEAD

Merge commit '2e9f1204ca01c3e20898d4a67c8b84899d394a88' into HEAD

Merge commit '459bbb422' into HEAD

Merge commit '67920f797511c360b25dab4d30730be304848f32' into HEAD

Merge commit '65e1dc4d9' into HEAD

Merge commit 'e8e598f6415461e7fe957eec1bee6afb55927d59' into HEAD

Merge commit '3e358a682' into HEAD

Merge commit 'a670ff888437f4b6a3d24cc2996e9f969a87cbae' into HEAD

Merge commit '31519bb39' into HEAD

Merge commit 'b6d59f2bb4fae0ba4f74e2c967b5e2f777f8c860' into HEAD

Merge commit '8231fee46' into HEAD