Specifically as it relates to the ABA problem.

Simplify feature representation in CargoConfig

Simplify

Remove reference to Toggle inlay hints

This simply removes the reference to the `Toggle inlay hints` action after its removal in rust-lang/rust-analyzer#13215.
In fact, this reference is still visible [in the User Manual here](https://rust-analyzer.github.io/manual.html#inlay-hints).

…ykril

Ensure at least one trait bound in `TyKind::DynTy`

One would expect `TyKind::DynTy` to have at least one trait bound, but we may produce a dyn type with no trait bounds at all. This patch prevents it by returning `TyKind::Error` in such cases.

An "empty" dyn type would have caused panic during method resolution without rust-lang#13257. Although already fixed, I think an invariant to never produce such types would help prevent similar problems in the future.

Simplify

feat: Display the value of enum variant on hover

fixes rust-lang#12955

This PR adds const eval support for enums, as well as showing their value on hover, just as consts currently have.

I developed these two things at the same time, but I've realized now that they are separate. However since the hover is just a 10 line change (not including tests), I figured I may as well put them in the same PR. Though if you want them split up into "enum const eval support"  and "show enum variant value on hover", I think that's reasonable too.

Since this adds const eval support for enums this also allows consts that reference enums to have their values computed now too.

The const evaluation itself is quite rudimentary, it doesn't keep track of the actual type of the enum, but it turns out that Rust doesn't actually either, and `E::A as u8` is valid regardless of the `repr` on `E`.

It also doesn't really care about what expression the enum variant contains, it could for example be a string, despite that not being allowed, but I guess it's up to the `cargo check` diagnostics to inform of such issues anyway?

Properly set the enum variant body type from the repr attribute

Follow up for rust-lang/rust-analyzer#12966, fixes some type inference problems

See microsoft/language-server-protocol#1341

proc-macro ABI breakage still affects the tests when a new stable version
releases. Ideally we'd still be able to run the tests on the rust-analyzer
repo without having to update the proc-macro ABI, but for now just to
unblock CI we will ignore them here, as they are still run in upstream.

Don't run proc-macro-srv tests on the rust-analyzer repo

proc-macro ABI breakage still affects the tests when a new stable version releases. Ideally we'd still be able to run the tests on the rust-analyzer repo without having to update the proc-macro ABI, but for now just to unblock CI we will ignore them here, as they are still run in upstream.

Properly support IDE functionality in enum variants

Fix diagnostics not working in enum variant bodies

cc rust-lang/rust-analyzer#12966

… r=Veykril

Use the sysroot proc-macro server for analysis-stats

Should fix the metrics issues

…Veykril

feat: type inference for generators

This PR implements basic type inference for generator and yield expressions.

Things not included in this PR:
- Generator upvars and generator witnesses are not implemented. They are only used to determine auto trait impls, so basic type inference should be fine without them, but method resolutions with auto trait bounds may not be resolved correctly.

Open questions:
- I haven't (yet) implemented `HirDisplay` for `TyKind::Generator`, so generator types are just shown as "{{generator}}" (in tests, inlay hints, hovers, etc.), which is not really nice. How should we show them?
- I added moderate amount of stuffs to minicore. I especially didn't want to add `impl<T> Deref for &T` and `impl<T> Deref for &mut T` exclusively for tests for generators; should I move them into the test fixtures or can they be placed in minicore?

cc rust-lang#4309

Feature: Add assist to unwrap tuple declarations

> Implement rust-lang#12923 for only tuples.
>
> Does not implement unwrapping for structs, as mentioned in the issue.

Add assist to unwrap tuples declarations to separate declarations.

```rust
fn main() {
	$0let (foo, bar, baz) = (1.0, "example", String::new())
}
```

becomes:

```rust
fn main() {
	let foo = 1.0;
	let bar = "example";
	let baz = String::new();
}
```

## Changelog

### Feature

- Added assist to unwrap tuple declarations.

Fix find_path using the wrong module for visibility calculations

Remove obsolete in-rust-tree feature from sourcegen

…ields, r=Veykril

Emit unconfigured code diagnostics for enum variants and struct/union fields

Fixes rust-lang/rust-analyzer#12664

…name, r=Veykril

Fix PackageInformation having the crate name instead of package name

The `PackageInformation` type from the LSIF PR used the _crate_ name instead of the _package_ name. This caused issues when looking up crates by this name on the Sourcegraph backend, where we sync crate contents, for crates such as actix-web and many of its components (actix-files, actix-http etc etc), see screenshot 1 for the observed symptom.

This PR hasnt been tested on other entry points besides cargo (such as project json).

See screenshot 2 for the change in behaviour via SCIP snapshot comparison.

<details>
<summary>Screenshot 1</summary>

![crates.io giving 404](https://user-images.githubusercontent.com/18282288/192286637-8bf7c333-4441-4e60-8cce-de7eaa11ee9f.png)

</details>

<details>
<summary>Screenshot 2</summary>

![before and after from SCIP snapshot output](https://user-images.githubusercontent.com/18282288/192287733-d7e73ff0-abbc-4ae5-82d0-bf9dc45d755c.png)

</details>

Follow-up PR to my question over at the [rust-lang Zulip](https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Frust-analyzer/topic/canonical.20crate.20name.20confusion.20for.20monikers), excuse any incorrect usages of the term package vs crate.

Use cfg(any()) instead of cfg(FALSE) for disabling proc-macro test

cc rust-lang/rust-analyzer#13286

When receiving multiple change events for a single file id where the
last change is a delete the server panics, as it tries to access the
file contents of a deleted file. This occurs due to the VFS changes and
the in memory file contents being updated immediately, while
`process_changes` processes the events afterwards in sequence which no
longer works as it will only observe the final file contents. By
folding these events together, we will no longer try to process these
intermediate changes, as they aren't relevant anyways.

Potentially fixes rust-lang/rust-analyzer#13236

Amalgamate file changes for the same file ids in process_changes

When receiving multiple change events for a single file id where the last change is a delete the server panics, as it tries to access the file contents of a deleted file. This occurs due to the VFS changes and the in memory file contents being updated immediately, while `process_changes` processes the events afterwards in sequence which no longer works as it will only observe the final file contents. By folding these events together, we will no longer try to process these intermediate changes, as they aren't relevant anyways.

Potentially fixes rust-lang/rust-analyzer#13236

Add RequestFailed error code, as per spec 3.17

See microsoft/language-server-protocol#1341

docs(guide): fix Analysis and AnalysisHost doc links

Don't retry requests that have already been cancelled

…r=Veykril

Make assist tests panic again on empty source changes

…Veykril

fix: infer for-loop item type with `IntoIterator` and `Iterator`

Part of rust-lang#13299

We've been inferring the type of the yielded values in for-loop as `<T as IntoIterator>::Item`. We infer the correct type most of the time when we normalize the projection type, but it turns out not always. We should infer the type as `<<T as IntoIterator>::IntoIter as Iterator>::Item`.

When one specifies `IntoIter` assoc type of `IntoIterator` but not `Item` in generic bounds, we fail to normalize `<T as IntoIterator>::Item` (even though `IntoIter` is defined like so: `type IntoIter: Iterator<Item = Self::Item>` - rustc does *not* normalize projections based on other projection's bound I believe; see [this playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=e88e19385094cb98fadbf647b4c2082e)).

Note that this doesn't fully fix # 13299 - given the following code, chalk can normalize `<I as IntoIterator>::IntoIter` to `S`, but cannot normalize `<S as Iterator>::Item` to `i32`.

```rust
struct S;
impl Iterator for S { type Item = i32; /* ... */ }
fn f<I: IntoIterator<IntoIter = S>>(it: I) {
    for elem in it {}
      //^^^^{unknown}
}
```

This is because chalk finds multiple answers that satisfy the query `AliasEq(<S as Iterator>::Item = ?X`: `?X = i32` and `?X = <I as IntoIterator>::Item` - which are supposed to be the same type due to the aforementioned bound on `IntoIter` but chalk is unable to figure it out.

Fix requests not being retried anymore

Fix type alias hovers not rendering generic parameters

Fix annotations not resolving when lens location is set to whole item

Fixes rust-lang/rust-analyzer#13310

Fix move_format_string_arg being tokentree unaware

Fixes rust-lang/rust-analyzer#13261

Fix trait impl item completions using macro file text ranges

Fixes rust-lang/rust-analyzer#13323

…explicitly

Do not use the sysroot proc-macro server when a server path is given explicitly

Add config for supplying sysroot path

Add proc-macro dependency to rustc crates

This commit "inverts" the order of generic parameters/arguments of an
item and its parent. This is to fulfill chalk's expectation on the
order of `Substitution` for generic associated types and it's one step
forward for their support (hopefully).

Although chalk doesn't put any constraint on the order of `Substitution`
for other items, it feels natural to get everything aligned rather than
special casing GATs.

One complication is that `TyBuilder` now demands its users to pass in
parent's `Substitution` upon construction unless it's obvious that the
the item has no parent (e.g. an ADT never has parent). All users
*should* already know the parent of the item in question, and without
this, it cannot be easily reasoned about whether we're pushing the
argument for the item or for its parent.

Quick comparison of how this commit changes `Substitution`:

```rust
trait Trait<TP, const CP: usize> {
  type Type<TC, const CC: usize> = ();
  fn f<TC, const CC: usize>() {}
}
```

- before this commit: `[Self, TP, CP, TC, CC]` for each trait item
- after this commit: `[TC, CC, Self, TP, CP]` for each trait item

Prioritize restart messages in flycheck

cc rust-lang/rust-analyzer#12936 (comment)

…, r=Veykril

internal: change generic parameter order

tl;dr: This PR changes the `Substitution` for trait items and methods like so:

```rust
trait Trait<TP, const CP: usize> { // note the implicit Self as first parameter
  type Type<TC, const CC: usize>;
  fn f<TC, const CC: usize>() {}
}
impl<TP, const CP: usize> S {
  fn f<TC, const CC: usize>() {}
}
```

- before this PR: `[Self, TP, CP, TC, CC]` for each trait item, `[TP, CP, TC, CC]` for `S::f`
- after this PR: `[TC, CC, Self, TP, CP]` for each trait item, `[TC, CC, TP, CP]` for `S::f`

---

This PR "inverts" the generic parameters/arguments of an item and its parent. This is to fulfill [chalk's expectation](https://github.com/rust-lang/chalk/blob/d875af0ff196dd6430b5f5fd87a640fa5ab59d1e/chalk-solve/src/rust_ir.rs#L498-L502) on the order of generic arguments in `Substitution`s for generic associated types and it's one step forward for GATs support (hopefully). Although chalk doesn't put any constraint for other items, it feels more natural to get everything aligned than special casing GATs.

One complication is that `TyBuilder` now demands its users to pass in parent's `Substitution` upon construction unless it's obvious that the the item has no parent (e.g. an ADT never has parent). All users *should* already know the parent of the item in question, and without this, it cannot be easily reasoned about whether we're pushing the argument for the item or for its parent.

Some additional notes:
- f8f5a5e: This isn't related to the change, but I felt it's nicer.

- 78977cd: There's one major change here other than the generic param order: Default arguments are now bound by the same `Binder` as the item in question rather than a `Binder` limited to parameters they can refer to (i.e. arguments that syntactically appear before them). Now that the order of generic parameters is changed, it would be somewhat complicated to make such `Binder`s as before, and the "full" `Binder`s shouldn't be a problem because we already make sure that the default arguments don't refer to the generic arguments after them with `fallback_bound_vars()`.

- 7556f74: This is split from 4385d3d to make it easy to revert if it turns out that the GATs with const generics panic is actually not resolved with this PR. cc rust-lang#11878 rust-lang#11957