…u when clauses to prevent irrelevant commands in non-rust files

- Remove unnecessary references and derefs
- Manual formatting

… docs command

minor: Sync from downstream

minor: Remove file added by mistake

This got added somehow in rust-lang/rust-analyzer#14154.

minor: Try to improve the `rustfmt.overrideCommand` docs

Closes rust-lang#14078

(This is a large commit. The changes to
`compiler/rustc_middle/src/ty/context.rs` are the most important ones.)

The current naming scheme is a mess, with a mix of `_intern_`, `intern_`
and `mk_` prefixes, with little consistency. In particular, in many
cases it's easy to use an iterator interner when a (preferable) slice
interner is available.

The guiding principles of the new naming system:
- No `_intern_` prefixes.
- The `intern_` prefix is for internal operations.
- The `mk_` prefix is for external operations.
- For cases where there is a slice interner and an iterator interner,
  the former is `mk_foo` and the latter is `mk_foo_from_iter`.

Also, `slice_interners!` and `direct_interners!` can now be `pub` or
non-`pub`, which helps enforce the internal/external operations
division.

It's not perfect, but I think it's a clear improvement.

The following lists show everything that was renamed.

slice_interners
- const_list
  - mk_const_list -> mk_const_list_from_iter
  - intern_const_list -> mk_const_list
- substs
  - mk_substs -> mk_substs_from_iter
  - intern_substs -> mk_substs
  - check_substs -> check_and_mk_substs (this is a weird one)
- canonical_var_infos
  - intern_canonical_var_infos -> mk_canonical_var_infos
- poly_existential_predicates
  - mk_poly_existential_predicates -> mk_poly_existential_predicates_from_iter
  - intern_poly_existential_predicates -> mk_poly_existential_predicates
  - _intern_poly_existential_predicates -> intern_poly_existential_predicates
- predicates
  - mk_predicates -> mk_predicates_from_iter
  - intern_predicates -> mk_predicates
  - _intern_predicates -> intern_predicates
- projs
  - intern_projs -> mk_projs
- place_elems
  - mk_place_elems -> mk_place_elems_from_iter
  - intern_place_elems -> mk_place_elems
- bound_variable_kinds
  - mk_bound_variable_kinds -> mk_bound_variable_kinds_from_iter
  - intern_bound_variable_kinds -> mk_bound_variable_kinds

direct_interners
- region
  - intern_region (unchanged)
- const
  - mk_const_internal -> intern_const
- const_allocation
  - intern_const_alloc -> mk_const_alloc
- layout
  - intern_layout -> mk_layout
- adt_def
  - intern_adt_def -> mk_adt_def_from_data (unusual case, hard to avoid)
  - alloc_adt_def(!) -> mk_adt_def
- external_constraints
  - intern_external_constraints -> mk_external_constraints

Other
- type_list
  - mk_type_list -> mk_type_list_from_iter
  - intern_type_list -> mk_type_list
- tup
  - mk_tup -> mk_tup_from_iter
  - intern_tup -> mk_tup

add openDocs command to context menu in VS Code extension

This adds the `openDocs` command to the VS Code context menu. I believe there are probably many user who are unaware of this command existing in the rust analyzer extension, and that this should enhance the discoverability of the command. Additionally, even if people are aware of this capability, it's helpful to have this in the context menu anyway; for example, one might forget the name of the command, or the keybinding they have assigned to it. I think that opening docs is a common enough action to warrant the extra line added to the context menu.

This makes a few other small changes as well. There are two minor style changes to increase style consistency. First, it changes the titles of the two commands that the rust analyzer extension will contribute to the context menu to title case. All standard VS Code commands that appear in the context menu are in title case. Second, it shortens the title of the `openDocs` command from `Open docs under cursor` to `Open Docs`. The implicit assumption in the standard VS Code context menu command titles is that the action applies to the symbol under the cursor: `Go to Definition`, `Find All References`, etc. Note that since these are changes to the command titles, rather than the command names themselves, these changes will not break any users' existing keybindings for these commands.

Second, this adds further restrictions to the `where` clauses of the two commands that the rust analyzer extension will contribute to the context menu, so that the two commands will appear in the context menu only when in a Rust project **and** within a Rust file. Say you have a Python or bash script inside your Rust project. Having these commands appear in the context menu when you right click a symbol in such a non-Rust file is extraneous and potentially confusing.

![demonstration](https://user-images.githubusercontent.com/6609145/219976062-b46ab21b-5753-48f5-a1da-562566cae71c.gif)

minor: import `Either` from `either`

This is a clean-up patch to replace `use itertools::Either` with `use either::Either` for the sake of consistency.

…=lnicola

fix: Add check for extra path segments after a fully qualified one

`type A = <()>;` is parsed just fine by rust-analyzer, but then rejected by rustc:

```
error: expected `::`, found `;`
 --> x.rs:7:14
  |
7 | type A = <()>;
  |              ^ expected `::`

```

Fixed by adding a lookahead for the `::` token after fully-qualified path segments.

Respect $CARGO_HOME when looking up toolchains.

Some people set `$CARGO_HOME` to a location other than `~/.cargo` (`$XDG_DATA_DIR/cargo`,  in my case), and I'd be a little nicer if the rust-analyzer extension and server respect that value when looking up toolchains, instead of having us configure all of `$CARGO`, `$RUSTC` ... manually.

The new implementation still defaults to `~/.cargo` if `$CARGO_HOME` is unset, pretty much like cargo itself does (as documented in https://doc.rust-lang.org/cargo/guide/cargo-home.html), so the change is backwards compatible for most people except those who has configured `$CARGO_HOME` explicitly.

I considered using https://crates.io/crates/home as suggested by https://doc.rust-lang.org/cargo/guide/cargo-home.html, but decided to put int on hold because i) we need mirror impl in node, ii) I thought the consistency matters more and iii) the new implementation shouldn't be worse than the current one (i.e. switching to `home` improvement is rather orthogonal and could be done in another PR). If you have any directions on this, please let me know.

fix:add a case in which remainig is None in resolveing types when resolving hir path.

fix rust-lang#14030 The variable type is being determined incorrectly
This PR fixed a problem in which `go to definition` is jumping to the incorrect position because it was failing to resolve the type in case it defined in the module when resolving hir.
In addition, I added a test for this issue and refactored the related code.
This is my first PR and I am using a translation tool to write this text. Let me know if you have any problems.

add: clean api to get `raw_ptr` type

There doesn't seem to be an API to fetch the type of `raw_ptr`, which is helpful for a project I work on.

Notes:

- I am unsure about the function name, do let me know if I should use something else.
- Also unsure about where to add tests, for hir changes. Will fix it as needed.

minor: Simplify

…ameters

Refactor method to get type parameters to add const parameters
Remove unused methods

Beginning of MIR

This pull request introduces the initial implementation of MIR lowering and interpreting in Rust Analyzer.

The implementation of MIR has potential to bring several benefits:
- Executing a unit test without compiling it: This is my main goal. It can be useful for quickly testing code changes and print-debugging unit tests without the need for a full compilation (ideally in almost zero time, similar to languages like python and js). There is a probability that it goes nowhere, it might become slower than rustc, or it might need some unreasonable amount of memory, or we may fail to support a common pattern/function that make it unusable for most of the codes.
- Constant evaluation: MIR allows for easier and more correct constant evaluation, on par with rustc. If r-a wants to fully support the type system, it needs full const eval, which means arbitrary code execution, which needs MIR or something similar.
- Supporting more diagnostics: MIR can be used to detect errors, most famously borrow checker and lifetime errors,  but also mutability errors and uninitialized variables, which can be difficult/impossible to detect in HIR.
- Lowering closures: With MIR we can find out closure capture modes, which is useful in detecting if a closure implements the `FnMut` or `Fn` traits, and calculating its size and data layout.

But the current PR implements no diagnostics and doesn't support closures. About const eval, I removed the old const eval code and it now uses the mir interpreter. Everything that is supported in stable rustc is either implemented or is super easy to implement. About interpreting unit tests, I added an experimental config, disabled by default, that shows a `pass` or `fail` on hover of unit tests (ideally it should be a button similar to `Run test` button, but I didn't figured out how to add them). Currently, no real world test works, due to missing features including closures, heap allocation, `dyn Trait` and ... so at this point it is only useful for me selecting what to implement next.

The implementation of MIR is based on the design of rustc, the data structures are almost copy paste (so it should be easy to migrate it to a possible future stable-mir), but the lowering and interpreting code is from me.

Fix: Run doctests for structs with lifetime parameters from IDE

Fixes rust-lang#14142: Doctests can't be triggered for structs with lifetimes

This MR adds lifetime parameters to the structs path for runnables so that they can be triggered from an IDE as well.

This is my first MR for rust-analyzer, please let me know if I should change something, either in code or the description here.

Deduplicate source roots that have overlapping include paths

Fixes flycheck not working for the rustc workspace when using `linkedProjects`

…e, r=lnicola

minor: Don't use unstable `pointer` link

Our CI is failing because rustdoc is complaining we're using [unstable](rust-lang#80896) `pointer` link.

Support removing nested `dbg!()`s in `remove_dbg`

Closes rust-lang#13901

Add tuple to render_const_scalar

cc `@lowr`

…, r=Veykril

Fix associated item visibility in block-local impls

Fixes rust-lang#14046

When we're resolving visibility of block-local items...

> `self` normally refers to the containing non-block module, and `super` to its parent (etc.). However, visibilities must only refer to a module in the DefMap they're written in, so we restrict them when that happens. ([link])

 ...unless we're resolving visibility of associated items in block-local impls, because that impl is semantically "hoisted" to the nearest (non-block) module. With this PR, we skip the adjustment for such items.

Since visibility representation of those items is modified, this PR also adjusts visibility rendering in `HirDisplay`.

[link]: https://github.com/rust-lang/rust-analyzer/blob/a6603fc21d50b3386a488c96225b2d1fd492e533/crates/hir-def/src/nameres/path_resolution.rs#L101-L103

Don't drop rustc crates in the rustc workspace

Turns out the rustc workspace has tools that rely on the external crates themselves so this check is faulty

…cal-crates, r=Veykril

feat: allow `generate_function` to generate in different local crate

Closes rust-lang#14224

This PR allows `generate_function` assist to generate in crates other than the current one. I took a step further from the original request and made it allow to generate in any local crates since it looked reasonable and IDE layer doesn't really know about packages.

(actually we have been checking which crate we're generating in only for methods and not for freestanding functions, so we were providing the assist for `std::foo$0()`; it's both feature and fix in a sense)

The first commit is a drive-by fix unrelated to the feature.

Show pattern mismatch diagnostics

fix: Load the sysroot in all CLI commands

Since we moved impl trait handling to other place, there are only two
cases now: those that introduce implicit `Self` parameter and those that
don't.

Handle trait alias definitions

Part of rust-lang#2773

This PR adds a bunch of structs and enum variants for trait aliases. Trait aliases should be handled as an independent item because they are semantically distinct from traits.

I basically started by adding `TraitAlias{Id, Loc}` to `hir_def::item_tree` and iterated adding necessary stuffs until compiler stopped complaining what's missing. Let me know if there's still anything I need to add.

I'm opening up this PR for early review and stuff. I'm planning to add tests for IDE functionalities in this PR, but not type-related support, for which I put FIXME notes.

Diagnose value breaks in incorrect breakables

feat: Diagnose unresolved field, method call and call expression

Disable pattern type mismatches again

We have too many false mismatches at the moment for these to be enabled
cc rust-lang/rust-analyzer#14222

rust-analyzer used the token at the cursor after macro expansion
to decide whether to replace the token at the cursor before macro
expansion. In most cases these two are the same but in some cases these
can mismatch which can lead to incorrect replacements.

For example if an ident/expr macro argument is missing rust-analyzer
generates a "missing" identifier as a placeholder, there is only a
brace at the cursor. Therefore, rust-analyzer will incorrectly replace
the macro brace with the completion in that case leading to rust-lang#14246.

Using the expanded token type was intentional. However, this doesn't
seem to ever be desirable (this is supported by the fact that there
were no tests that relied on this behavior) since the type of edit to
perform should always be determined by the token it's actually applied
to.

generate correct completion edits for missing macro arguments

Fixes rust-lang#14246

rust-analyzer used the token at the cursor after macro expansion to decide whether to replace the token at the cursor before macro expansion. In most cases these two are the same but in some cases these can mismatch which can lead to incorrect replacements.

For example if an ident/expr macro argument is missing rust-analyzer generates a "missing" identifier as a placeholder, there is only a brace at the cursor. Therefore, rust-analyzer will incorrectly replace the macro brace with the completion in that case leading to rust-lang#14246.

Using the expanded token type was intentional. However, this doesn't seem to ever be desirable (this is supported by the fact that there were no tests that relied on this behavior) since the type of edit to perform should always be determined by the token it's actually applied to. Therefore this PR simply switches the relevant match to use the unexpanded token instead

internal: Report type metrics for patterns

```
❯ cargo run --release -p rust-analyzer -q analysis-stats --memory-usage .
Database loaded:     2.09s, 218mb (metadata 275.07ms, 21mb; build 1.29s, 504kb)
  crates: 44, mods: 916, decls: 19582, fns: 14631
Item Collection:     14.33s, 472mb
  exprs: 420422, ??ty: 68 (0%), ?ty: 141 (0%), !ty: 1
  pats: 82968, ??ty: 11 (0%), ?ty: 10 (0%), !ty: 178
Inference:           47.84s, 745mb
Total:               62.16s, 1217mb
```
We currently have 178 mismatches on r-a itself

internal: Set expectation for no-semi expression statements to unit

…olve to

internal: Handle fields called as method calls as the fields they resolve to

Confusing PR title tbf but this makes it so `bar` in `foo.bar()` resolves to the field if it exists and no method with the same name exists. Improves UX slightly when incorrectly calling a field.

…leywiser

Make compressed rmeta contain compressed data length after header

Fixes rust-lang#90056, which is caused by link.exe introducing padding to the `.rustc` section, since it assumes this will have no effect besides allowing it to possibly use the extra space in future links.

…very expression change

…ecting them everytime

Bring back the hex in const hover

fix: Adjust `replace_match_with_if_let` applicability range

It currently trigger in the entirety of match which is less than ideal

internal: Re-use the resolver in `InferenceContext` instead of rebuilding it whenever needed

This reduced inference time on my local build by roughly ~1 sec (out of like 60)