Revert "fix: in VSCode, correctly resolve relative paths to errors"

Auto merge of #13401 - lnicola:opt-tests, r=lnicola

Run `analysis-stats` on CI, with `opt-level = 1`

We might want to run `analysis-stats` on PRs, and this makes it less unbearable.

Run analysis-stats on CI

Avoid format! in favor of to_string

Set opt-level = 1 on dev profile

Auto merge of #13358 - btwotwo:feature/env-vars-autocompletion, r=Veykril

feat: Autocomplete Cargo-defined env vars in `env!` and `option_env!` (#12448)

Closes #12448

Important to know:

- Variables are taken from https://doc.rust-lang.org/cargo/reference/environment-variables.html and hardcoded as a const array.
- For the sake of simplicity I didn't include the autocompletion of `CARGO_BIN_EXE_<name>` and `OUT_DIR` since it would require information about build.rs and binary name. If somebody knows an easy way of obtaining them I can add those vars as well :)

Formatting

Fix formatting for cargo vars list

Rename `get_outer_macro` to `macro_call_for_string_token`

Remove extra parameter, access Db through semantics

Auto merge of #13382 - lowr:fix/reorder-dyn-bounds-on-render, r=lowr

fix: reorder dyn bounds on render

Fixes #13368

#13192 changed the order of dyn bounds, violating the [contract](https://github.com/rust-lang/rust-analyzer/blob/3a69435af7a1e6273744085cb251adb2b9c30a03/crates/hir-ty/src/display.rs#L896-L901) with `write_bounds_like_dyn_trait()` on render. The projection bounds are expected to come right after the trait bound they are accompanied with.

Although the reordering procedure can be made a bit more efficient, I opted for relying only on the [invariants](https://github.com/rust-lang/rust-analyzer/blob/3a69435af7a1e6273744085cb251adb2b9c30a03/crates/hir-ty/src/lower.rs#L995-L998) currently documented in `lower_dyn_trait()`. It's not the hottest path and dyn bounds tend to be short so I believe it shouldn't hurt performance noticeably.

fix: reorder dyn bounds on render

Auto merge of #13357 - Veykril:minicore, r=Veykril

internal: Allow minicore flags specification to be order independent

Auto merge of #13329 - Veykril:rustc-proc-macro, r=Veykril

Use $crate instead of std for panic builtin_fn_macro

This should be closer to the expected output and gets rid of a few type mismatches in rustc/library

Auto merge of #13392 - Veykril:spec-pref, r=Veykril

Prefer similar tokens when expanding macros speculatively

Should improve completions in proc-macros in some cases

Prefer similar tokens when expanding macros speculatively

Auto merge of #13391 - dvdsk:update-manual, r=lnicola

Update manual now stable can be installed with rustup

this a new PR for #13374 as `bors squash` seemed to have broken `bors`
_______
`rustup` can now install `rust-analyzer` for the stable tool-chain. This commit removes the note that `rustup` can only install for the nightly branch and adjusts the command.

I also added a note on how to find the path to the `rust-analyzer` binary when installed using `rustup`, and suggestions on how to work around it not being placed in `~/.cargo/bin`.

I thought it would be ideal to point everyone to use `rustup run stable rust-analyzer` to start `rust-analyzer`. That would make it trivial to switch to nightly however I could not get this to work in `nvim` therefore I left it as a suggestion at the end.

Update manual now stable can be installed with rustup

`rustup` can now install `rust-analyzer` for the stable tool-chain. This commit removes the note that `rustup` can only install for the nightly branch and adjusts the command.

I also added a note on how to find the path to the `rust-analyzer` binary when installed using `rustup`, and suggestions on how to work around it not being placed in `~/.cargo/bin`.

I thought it would be ideal to point everyone to use `rustup run stable rust-analyzer` to start `rust-analyzer`. That would make it trivial to switch to nightly however I could not get this to work in `nvim` therefore I left it as a suggestion at the end.

Auto merge of #13386 - Veykril:completions-ref, r=Veykril

Refactor completions expansion

Depends on https://github.com/rust-lang/rust-analyzer/pull/13384
Diff is unfortunately massive as I changed the functions in the analysis module from associated ones to standalone (unfortunately without an extra commit)

Auto merge of #13380 - Veykril:cfg-pat-params, r=Veykril

Honor cfg attributes on params when lowering their patterns

Closes https://github.com/rust-lang/rust-analyzer/issues/13375

Auto merge of #13385 - Veykril:progress, r=Veykril

Don't report build-scripts and proc-macros as metadata progress

Seems somewhat confusing to me, given `metadata` is already the step we do for workspace loading

Refactor completions expansion

Don't report build-scripts and proc-macros are metadata progress

Auto merge of #13384 - Veykril:macro-fallbacks, r=Veykril

Expand unmatched mbe fragments to reasonable default token trees

Currently we expand unmatched fragments by not replacing them at all, leaving us with `$ident`. This trips up the parser or subsequent macro calls. Instead it makes more sense to replace these with some reasonable default depending on the fragment kind which should make more recursive macro calls work better for completions.

Expand unmatched mbe fragments to reasonable default token trees

Currently we expand unmatched fragments by not replacing them at all,
leaving us with `$ident`. This trips up the parser or subsequent macro
calls. Instead it makes more sense to replace these with some reasonable
default depending on the fragment kind which should make more recursive
macro calls work better for completions.

Auto merge of #13333 - feniljain:fix_assists, r=Veykril

fix(generate_method): correct method indentation inside generated impl and change gen loc

should fix #10619

Use $crate instead of std for panic builtin_fn_macro

This should be closer to the expected output and gets rid of a few
type mismatches in rustc/library

Auto merge of #13303 - jplatte:convert-named-struct-to-tuple-struct, r=Veykril

Add convert_named_struct_to_tuple_struct assist

Closes #11643, since the assist for converting in the other direction is already there (I based most of the implementation and all of the tests on it).

Auto merge of #13367 - matklad:fix-problem-matchers, r=Veykril

fix: in VSCode, correctly resolve relative paths to errors

VS Code problem matcher are restricted to be static "regexes". You can't create a problem matcher dynamically, and you can't use custom code in lieu of problem matcher.

This creates a problem for rust/cargo compiler errors. They use paths relative to the root of the Cargo workspace, but VS Code doesn't necessary know where that root is.

Luckily, there's a way out: our current problem matcher is defined like this:

    "fileLocation": [ "autoDetect", "${workspaceRoot}" ],

That means that relative pahts would be resoleved relative to workspace root. VS Code allows to specify a command inside `${}`. So we can plug custom logic there to fetch Cargo's workspace root!

And that's exactly what this PR is doing!

Honor cfg attributes on params when lowering their patterns

Auto merge of #13377 - DropDemBits:doc-link-underline-range, r=Veykril

fix: Underline only the intra-doc link itself instead of the whole doc comment

Auto merge of #13376 - DropDemBits:strip-generic-bounds-and-defaults, r=Veykril

internal: Add `GenericParamList::to_generic_args` and `{TypeParam,ConstParam}::remove_default` APIs

Also fixes `generate_impl` not removing the default const param value, though it seems that no one has encountered or reported that issue yet 😅

This initially started out as refactoring `utils::generate_impl_text_inner` to understand it better (which was the reason for adding `{TypeParam,ConstParam}::remove_default`), but ended up also finding another place that needed `GenericParamList::to_generic_args`, hence its addition in here.

Underline only the intra-doc link instead of the whole doc comment

Have `to_generic_args` return `ast::GenericArgList`

Add `{TypeParam, ConstParam}::remove_default`

Also includes a drive-by refactor of `utils::generate_impl_text_inner`,
since that's what drove this change

Add `GenericParamList::to_generic_args`

fix: in VSCode, correctly resolve relative paths to errors

VS Code problem matcher are restricted to be static "regexes". You can't
create a problem matcher dynamically, and you can't use custom code in
lieu of problem matcher.

This creates a problem for rust/cargo compiler errors. They use paths
relative to the root of the Cargo workspace, but VS Code doesn't
necessary know where that root is.

Luckily, there's a way out: our current problem matcher is defined like
this:

    "fileLocation": [ "autoDetect", "${workspaceRoot}" ],

That means that relative pahts would be resoleved relative to workspace
root. VS Code allows to specify a command inside `${}`. So we can plug
custom logic there to fetch Cargo's workspace root!

And that's exactly what this PR is doing!

Auto merge of #13366 - matklad:xflags, r=lnicola

internal: :arrow_up: xflags

The main change here should be that flags are not inhereted, so

   $ rust-analyzer analysis-stats . -v -v

would do what it should do

We also no longer Don\'t

internal: :arrow_up: xflags

The main change here should be that flags are not inhereted, so

   $ rust-analyzer analysis-stats . -v -v

would do what it should do

We also no longer Don\'t

Auto merge of #13362 - WaffleLapkin:go_to_def_fix_doc_include_str, r=Veykril

fix: Make go-to-def work for `#[doc = include_str!("path")]`

See the added test, go-to-def on `#[doc = include_str!("path$0")]` should navigate to `path`.

Fix go-to-def for `#[doc = include_str!("path")]`

Pass context to env vars completion

Restrict auto-completion for only built-in macros

Make helper method less specific

Formatting

Remove unnecessary dereference

Use helper method in is_format_string

Replace if with option, add detail for each env variable completion

Add tests for env var completion

Add const list of cargo-defined env variables with descriptions

Add helper method to get a macro name from passed string

Use expanded version of text for env var completion

Add stub for cargo environment variables auto completion

Auto merge of #13353 - wildbook:fix_type_inference_panic, r=Veykril

Fix assertion failure in type inference (#13352)

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

internal: Allow minicore flags specification to be order independent

Auto merge of #13356 - WaffleLapkin:go_to_def_shadow_include, r=Veykril

minor: Fix go-to-def for shadowed `include*!`

Add a check in go-to-def feature, so that we don't assume any macro named `include`/`include_str`/`include_bytes` is the builtin one.

Fix go-to-def for shadowed `include*!`

Fix assertion failure in type inference (#13352)

Auto merge of #13344 - lowr:patch/change-generic-param-order, r=Veykril

fix: use `BoundVar`s from current generic scope

Fixup for #13335, addresses https://github.com/rust-lang/rust-analyzer/pull/13339#issuecomment-1266654607

Before the change in generic parameter order, `BoundVar`s for trait reference didn't change whether you are in an impl's scope or in an associated item's scope. Now that item's generic params come before its parent's, we need to shift their indices when we are in an associated item's scope.

fix: use `BoundVar`s from current generic scope

Auto merge of #13342 - rust-lang:revert-13328-rustc-proc-macro, r=Veykril

Revert "Add proc-macro dependency to rustc crates"

1. This panics since it indexes into the wrong thing, so fixes https://github.com/rust-lang/rust-analyzer/issues/13340
2. This didn't fix what I thought it would either
Reverts rust-lang/rust-analyzer#13328

Revert "Add proc-macro dependency to rustc crates"

Auto merge of #13339 - lowr:patch/change-generic-param-order, r=Veykril

fix: treat enum variants as generic item on their own

Fixup for #13335

It turns out I tried to merge two procedures into one utility function without noticing the incompatibility.

This time I *did* run analysis-stats on the four crates and confirmed it doesn't crash and this patch doesn't cause regression.

fix: treat enum variants as generic item on their own

Auto merge of #13335 - lowr:patch/change-generic-param-order, 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:
- f8f5a5ea5788a846013545d63c9b46fd70cc4f7c: This isn't related to the change, but I felt it's nicer.

- 78977cd86cd17e008f94f8579d6a5aaebe46e69b: 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()`.

- 7556f74b1691276d12e4cf96eb2df8f74836cdc1: This is split from 4385d3dcd0df7713b3a35f31f11034f0a570adbd 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 #11878 #11957

Auto merge of #13338 - Veykril:flycheck, r=Veykril

Prioritize restart messages in flycheck

cc https://github.com/rust-lang/rust-analyzer/issues/12936#issuecomment-1264670905

Prioritize restart messages in flycheck

Remove hack

Adapt to the new generic parameter/argument order

Change generic parameter/argument order

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

refactor: use `cast()` instead of interning `GenericArgData`

Auto merge of #13328 - Veykril:rustc-proc-macro, r=Veykril

Add proc-macro dependency to rustc crates

Add proc-macro dependency to rustc crates

Auto merge of #13327 - Veykril:proc-macro-srv-config, r=Veykril

Add config for supplying sysroot path

Add config for supplying sysroot path

Auto merge of #13326 - Veykril:proc-macro-srv-config, r=Veykril

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

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

Auto merge of #13324 - Veykril:trait-impl-completion, r=Veykril

Fix trait impl item completions using macro file text ranges

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

Fix trait impl item completions using macro file text ranges

Auto merge of #13321 - Veykril:format-str-args, r=Veykril

Fix move_format_string_arg being tokentree unaware

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

Fix move_format_string_arg being tokentree unaware

Auto merge of #13318 - Veykril:annotations, r=Veykril

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

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

Auto merge of #13320 - Veykril:ty-alias-hover, r=Veykril

Fix type alias hovers not rendering generic parameters

Fix type alias hovers not rendering generic parameters

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

Auto merge of #13319 - Veykril:req-retry, r=Veykril

Fix requests not being retried anymore

Fix requests not being retried anymore

Auto merge of #13311 - lowr:fix/for-loop-item-resolution, r=Veykril

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

Part of #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: infer for-loop item type with `IntoIterator` and `Iterator`

Update outside test and generated code

Add convert_named_struct_to_tuple_struct assist

Auto merge of #13301 - Veykril:empty-assist-source-changes, r=Veykril

Make assist tests panic again on empty source changes

Make assist tests panic again on empty source changes

Auto merge of #13202 - Veykril:cancelled-retry, r=Veykril

Don't retry requests that have already been cancelled

Don't retry requests that have already been cancelled

Auto merge of #13272 - oknozor:master, r=Veykril

docs(guide): fix Analysis and AnalysisHost doc links

Auto merge of #13280 - alanz:errorcode-requestfailed, r=Veykril

Add RequestFailed error code, as per spec 3.17

See https://github.com/microsoft/language-server-protocol/issues/1341

Auto merge of #13237 - Veykril:process-changes, r=Veykril

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 https://github.com/rust-lang/rust-analyzer/issues/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 https://github.com/rust-lang/rust-analyzer/issues/13236

Auto merge of #13300 - Veykril:cfg-false, r=Veykril

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

cc https://github.com/rust-lang/rust-analyzer/pull/13286