…garding invocation strategy and location

Tested for two cases:
1. Simple Use
2. Complex Use

This honors the build script config, and is also simpler.

scip: Use load_workspace_at.

This honors the build script config, and is also simpler.

Switch to in-tree rustc dependencies with a cfg flag

We can use this flag to detect and prevent breakages in rustc CI. (see rust-lang#14846 and rust-lang#15569)

~The `IN_RUSTC_REPOSITORY` is just a placeholder. Is there any existing cfg flag that rustc CI sets?~

VSCode behaves strangely, allowing to navigate into label location, but
not allowing to apply hint's text edit, after hint is resolved.
See microsoft/vscode#193124 for details.

For now, stub hint resolution for VSCode specifically.

…eykril

Do not resolve inlayHint.textEdit for VSCode client

Closes rust-lang/rust-analyzer#15604

VSCode behaves strangely, allowing to navigate into label location, but not allowing to apply hint's text edit, after hint is resolved. See microsoft/vscode#193124 for details.

For now, stub hint resolution for VSCode specifically.

Update chalk version

This only pulls in one commit in Chalk, which is an improvement to inference for rust-analyzer: rust-lang/chalk#800

Give `unmerge_use` a label explaining what it will affect.

When I'm trying to clean up `use`s, I often feel uncertain about what exactly the effects of choosing an assist will be. This PR makes a small improvement to that by giving “Unmerge use” a label which names the root of the tree that it's going to move, when one exists.

There is no test because I didn't see, among the test helpers, a way to assert on the assist label (as opposed to filtering on it). However, I did test the change manually.

I looked into making a similar change to “Merge imports”, but that is considerably trickier.

…re, r=lnicola

Fix inlining closures from local variables and functions

Previously, closures were not properly wrapped in parentheses for the `inline_local_variable` and `inline_call` assists, leading to the usages being incorrectly called:

```rust
fn main() {
    let $0f = || 2;
    let _ = f();
}
```

Now produces:

```rust
fn main() {
    let _ = (|| 2)();
}
```

Instead of:

```rust
fn main() {
    let _ = || 2();
}
```

Closes rust-lang#15639

Documentation: Add parenthesis to the list of on-typing assists.

…-lints, r=Veykril

Refactor/fix clippy lints

As title says.

…kril

minor : Deunwrap inline call

rust-lang#15398 subtask 4. There is still one instance of unwrap, which I found pretty hard to change.

…=Veykril

feat: Bool to enum assist

This adds the `bool_to_enum` assist, which converts the type of boolean local variables, fields, constants and statics to a new `enum` type, making it easier to distinguish the meaning of `true` and `false` by renaming the variants.

Closes rust-lang#14779

Fix autoimport does nothing when importing trait that is as _ imports

Potentially fixes rust-lang#15128

There are two cases of imports:
1. With simple path
2. With use tree list (or say complex path).

On deeper inspection, the [`recursive_merge`](https://github.com/rust-lang/rust-analyzer/blob/994df3d6a31d39f11600f30a6df0b744b13937c1/crates/ide-db/src/imports/merge_imports.rs#L87) function (called by [`try_merge_trees_mut`)](https://github.com/rust-lang/rust-analyzer/blob/994df3d6a31d39f11600f30a6df0b744b13937c1/crates/ide-db/src/imports/merge_imports.rs#L69) is meaningful only in the case of complex path (i.e when the UseTree contains a UseTreeList).

The [`recursive_merge`](https://github.com/rust-lang/rust-analyzer/blob/994df3d6a31d39f11600f30a6df0b744b13937c1/crates/ide-db/src/imports/merge_imports.rs#L87) function has [match with `Ok` arm](https://github.com/rust-lang/rust-analyzer/blob/994df3d6a31d39f11600f30a6df0b744b13937c1/crates/ide-db/src/imports/merge_imports.rs#L106), that is only executed when both LHS and RHS has `PathSegment` with same `NameRef`. The removal of underscore is implemented in this arm in the case of complex path.

For simple paths, the underscore is removed by checking if both LHS and RHS are simple paths and if their `Path` is same (the check is done [here](https://github.com/rust-lang/rust-analyzer/blob/994df3d6a31d39f11600f30a6df0b744b13937c1/crates/ide-db/src/imports/merge_imports.rs#L74)) and remove the underscore if one is found (I made an assumption here that RHS will always be what rust-analyzer suggests to import, because at this point I'm not sure how to remove underscore with help of `ted::replace`).

…kril

triagebot exclude_labels -> exclude_titles

rust-lang/triagebot#1720

minor: Various small fixes

Although it doesn't panic now, further changes to how we recover from incomplete syntax
may cause this assist to panic. To mitigate this a test case has been added.

…arms, r=Veykril

Deunwrap add_missing_match_arms

Last subtask of rust-lang#15398

…ock, r=Veykril

minor : Deunwrap convert_comment_block and desugar_doc_comment

Closes subtask 13 of rust-lang#15398 . I still don't know a more idiomatic way for the for loops I added, any suggestion would make me happy.

extend check.overrideCommand and buildScripts.overrideCommand docs

Extend check.overrideCommand and buildScripts.overrideCommand docs regarding invocation strategy and location.

However something still seems a bit odd -- the docs for `invocationStrategy`/`invocationLocation` talk about "workspaces", but the setting that controls which workspaces are considered is called `linkedProjects`. Is a project the same as a workspace here or is there some subtle difference?

add option to show full function signatures in completion docs

implements rust-lang#15538

with `"rust-analyzer.completion.fullFunctionSignatures.enable": false`:
![image](https://github.com/rust-lang/rust-analyzer/assets/59714841/ff739ad1-9975-461f-a62d-22c7823e7b71)

with `"rust-analyzer.completion.fullFunctionSignatures.enable": true`:
![image](https://github.com/rust-lang/rust-analyzer/assets/59714841/9bc98300-cef6-44ef-a353-dcf35cd36fce)

…albasi

minor: hover_simple refactor

A minor refactor of `hover_simple` opportunity I noticed while skimming through the code.

- `if let`s -> `match`
- `iter::once(x).cycle` -> `iter::repeat`
- `classify_token` -> `classify_node`

`cargo update -p libc`

Add `unused_variables` native diagnostic

…cola

internal: De-`unwrap` `generate_function.rs`

Fixes rust-lang/rust-analyzer#15398 (comment)

cc `@Inicola`

Simplify

minor: update libc to 0.2.148

This update is a follow-up for [rust-lang#112374](rust-lang#112374).

The command that does this update:

`cargo update -p libc`

…ch, r=Veykril

fix: panic with wrapping/unwrapping result return type assists

With the `wrap_return_type_in_result` assist, the following code results in a panic (note the lack of a semicolon):

```rust
fn foo(num: i32) -> $0i32 {
    return num
}

=>

thread 'handlers::wrap_return_type_in_result::tests::wrap_return_in_tail_position' panicked at crates/syntax/src/ted.rs:137:41:
called `Option::unwrap()` on a `None` value
```

I think this is because it first walks the body expression to change any `return` expressions and then walks all tail expressions, resulting in the `return num` being changed twice since it is both a `return` and in tail position. This can also happen when a `match` is in tail position and `return` is used in a branch for example. Not really sure how big of an issue this is in practice though since this seems to be the only case that is impacted and can be reduced to just `num` instead of `return num`.

This also occurs with the `unwrap_result_return_type` assist but panics with the following instead:

```
thread 'handlers::unwrap_result_return_type::tests::wrap_return_in_tail_position' panicked at /rustc/3223b0b5e8dadda3f76c3fd1a8d6c5addc09599e/library/alloc/src/string.rs:1766:29:
assertion failed: self.is_char_boundary(n)
```

Co-authored-by: Laurențiu Nicola <lnicola@users.noreply.github.com>

…io, r=lnicola

Improve useRustcErrorCode description

Fixes rust-lang#15666

Allocate ast ids for parameters

Since these can have attributes attached to them, we'll need this sooner or later (sooner being me tinkering with the token map right now)

Re-use the LSP config json for simplicity.

scip: Allow customizing cargo config.

Re-use the LSP config json for simplicity.

…ykril

fix: make bool_to_enum assist create enum at top-level

This pr makes the `bool_to_enum` assist create the `enum` at the next closest module block or at top-level, which fixes a few tricky cases such as with an associated `const` in a trait or module:

```rust
trait Foo {
    const $0BOOL: bool;
}

impl Foo for usize {
    const BOOL: bool = true;
}

fn main() {
    if <usize as Foo>::BOOL {
        println!("foo");
    }
}
```

Which now properly produces:

```rust
#[derive(PartialEq, Eq)]
enum Bool { True, False }

trait Foo {
    const BOOL: Bool;
}

impl Foo for usize {
    const BOOL: Bool = Bool::True;
}

fn main() {
    if <usize as Foo>::BOOL == Bool::True {
        println!("foo");
    }
}
```

I also think it's a bit nicer, especially for local variables, but didn't really know to do it in the first PR :)