…and-pms-component

This removes some RPC when creating and emitting diagnostics, and
simplifies the bridge slightly.

After this change, there are no remaining methods which take advantage
of the support for `&mut` references to objects in the store as
arguments, meaning that support for them could technically be removed if
we wanted. The only remaining uses of immutable references into the
store are `TokenStream` and `SourceFile`.

…adowing-another-type, r=estebank

Point at a type parameter shadowing another type

This patch fixes a part of rust-lang#97459.

proc_macro/bridge: send diagnostics over the bridge as a struct

This removes some RPC when creating and emitting diagnostics, and
simplifies the bridge slightly.

After this change, there are no remaining methods which take advantage
of the support for `&mut` references to objects in the store as
arguments, meaning that support for them could technically be removed if
we wanted. The only remaining uses of immutable references into the
store are `TokenStream` and `SourceFile`.

r? `@eddyb`

This fixes a typo first appearing in rust-lang#94624
in which test-macro diagnostic uses "a" article twice.

Since I searched sources for " a a " sequences,
I also fixed the same issue in a few source files where I found it.

Signed-off-by: Petr Portnov <[email protected]>

initial josh subtree sync

This demonstrates what a josh-based rustup would look like with my patched josh. To create it I did
```
git fetch http://localhost:8000/rust-lang/rust.git:start=75dd959a3a40eb5b4574f8d2e23aa6efbeb33573[:prefix=src/tools/miri]:/src/tools/miri.git master
git merge FETCH_HEAD
./rustup-toolchain HEAD && ./miri fmt
git commit -am rustup
```
Unlike the [previous attempt](rust-lang/miri#2554), this does not add a new root commit to the repo.

Once we merge this, we committed to using josh for subtree syncing, and in particular a version of josh that includes josh-project/josh#961 (or something compatible).

It's easy to just use `unescape_literal` + `byte_from_char`.

…=matklad

Unescaping cleanups

Some code improvements, and some error message improvements.

Best reviewed one commit at a time.

r? ````@matklad````

…r=lnicola

⬆️ rust-analyzer

r? ``@ghost``

currently only works with struct pattern

and remove unnecessary check

change struct_rest_pat to guarentee a HoverResult

Move token and node matching out of struct_rest_pat into hover

Co-authored-by: Lukas Wirth <[email protected]>

seems to fix rust-lang#13634

This fixes a regression introduced by rust-lang#13290, in which failing to set
`checkOnSave/target` (or `checkOnSave/targets`) would lead to an invalid
config.

…kril

Handle sysroot config in detached-files workspaces

…ock, r=jonas-schievink

Suppress "Implement default members" inside contained items

Fixes rust-lang#13561

…et, r=jonas-schievink

Fix: Handle empty `checkOnSave/target` values

This fixes a regression introduced by rust-lang#13290, in which failing to set `checkOnSave/target` (or `checkOnSave/targets`) would lead to an invalid config.

[Fixes rust-lang#13660]

Properly implement Drop for JodGroupChild

Add assist to generate trait impl's

resolves rust-lang#13553

This pull request adds a `generate_trait_impl` assist, which generates trait impl's for a type. It is almost the same as the one to generate impl's and I also reduced the trigger range to only outside the `RecordFieldList`. Also moved all the tests into separate test functions. A few of the old tests seemed redundant, so I didn't port them.

…ansion, r=Veykril

hir-expand: fix compile_error! expansion not unquoting strings

expanding `compile_error!` would not properly unquote strings, leading to quite ugly diagnostic messages:

![image](https://user-images.githubusercontent.com/5489149/202893481-2486ede8-c79a-4972-9713-416d6a704064.png)

this fixes it, using the conveniently placed `unquote_str` function, which now makes errors look like:

![image](https://user-images.githubusercontent.com/5489149/202893466-0763efad-9240-4d55-80a6-6c62000d5d2b.png)

additionally, using `unquote_str` has the cool side-effect of *also* handling raw strings, so this fixes a fixme too!

Add `deriveHelper` to `semanticTokenTypes` section of package.json

Co-authored-by: Lukas Wirth <[email protected]>

…, r=Veykril

feat: adds hover hint to ".." in record pattern

Hovering on the "rest" pattern in struct destructuring,
```rust
struct Baz {
    a: u32,
    b: u32,
    c: u32,
    d: u32
}

let Baz { a, b, ..$0} = Baz { a: 1, b: 2, c: 3, d: 4 };
```
shows:

```
.., c: u32, d: u32
```

Currently only works with struct patterns.

![image](https://user-images.githubusercontent.com/51814158/202837115-f424cc26-c2d7-4027-8eea-eeb7749ad146.png)

… shorthands

Improve goto declaration

Closes rust-lang/rust-analyzer#13599

- goto decl now goes to assoc items of trait declarations over the items of trait implementations
- goto decl now goes to the field declaration (opposed to goto def which shows both the field decl and binding created/local being used)
- also adds back the goto definition fallback that seems to have been dropped at some point.

…ykril

fix: tuple to named struct inside macros

seems to fix rust-lang#13634

Mega-sync from `rust-lang/rust`

This essentially implements `@oli-obk's` suggestion here rust-lang/rust-analyzer#13459 (comment), 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) a2a1d99 ⬆️ rust-analyzer
(x) 79923c3 ⬆️ rust-analyzer
(x) c60b1f6 ⬆️ rust-analyzer
(x) 8807fc4 ⬆️ rust-analyzer
(x) a99a48e ⬆️ rust-analyzer
(x) 4f55ebb ⬆️ rust-analyzer
(x) f5fde4d ⬆️ rust-analyzer
(x) 459bbb4 ⬆️ rust-analyzer
(x) 65e1dc4 ⬆️ rust-analyzer
(x) 3e358a6 ⬆️ rust-analyzer
(x) 31519bb ⬆️ rust-analyzer
(x) 8231fee ⬆️ rust-analyzer
(x) 22c8c9c ⬆️ rust-analyzer
(x) 9d2cb42 ⬆️ 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 `⬆️ 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 rust-lang#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 <[email protected]>
Date:   Fri Nov 25 13:28:24 2022 +0100

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

commit 0513fc02a08ea9de952983624bd0a00e98044b36
Merge: 38c98d1 6918009
Author: Amos Wenger <[email protected]>
Date:   Fri Nov 25 13:28:02 2022 +0100

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

commit 9ce6a734f37ef8e53689f1c6f427a9efafe846bd (final-sync)
Author: Amos Wenger <[email protected]>
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 rust-lang/rust-analyzer#13459 (comment)

> 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.

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.

…ue4u

fix: filter unnecessary completions after colon

close rust-lang#13597
related: rust-lang#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 rust-lang/rust-analyzer#13611 (comment)

…r=Veykril

fix: check tail expressions more precisely in `extract_function`

Fixes rust-lang#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 rust-lang#7840, rust-lang#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 rust-lang#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).