…on cfgs

Add an explanatory sentence and some sample code to help
readers understand why this struct exists.

minor: Add a doc comment for OpQueue

Add an explanatory sentence and some sample code to help readers understand why this struct exists.

…ebold

internal: Be more resilient to bad language item definitions in binop inference

Fixes rust-lang#16287
Fixes rust-lang#16286

There's one more in `write_fn_trait_method_resolution`, but I'm not sure if it won't cause further problems in `infer_closures`.

fix: Panic while canonicalizing erroneous projection type

Fixes rust-lang#17866

The root cause of rust-lang#17866 is quite horrifyng 😨

```rust
trait T {
    type A;
}

type Foo = <S as T>::A; // note that S isn't defined

fn main() {
    Foo {}
}
```

While inferencing alias type `Foo = <S as T>::A`;

https://github.com/rust-lang/rust-analyzer/blob/78c2bdce860dbd996a8083224d01a96660dd6a15/crates/hir-ty/src/infer.rs#L1388-L1398

the error type `S` in it is substituted by inference var in L1396 above as below;

https://github.com/rust-lang/rust-analyzer/blob/78c2bdce860dbd996a8083224d01a96660dd6a15/crates/hir-ty/src/infer/unify.rs#L866-L869

This new inference var's index is `1`, as the type inferecing procedure here previously inserted another inference var into same `InferenceTable`.

But after that, the projection type made from the above then passed to the following function;

https://github.com/rust-lang/rust-analyzer/blob/78c2bdce860dbd996a8083224d01a96660dd6a15/crates/hir-ty/src/traits.rs#L88-L96

here, a whole new `InferenceTable` is made, without any inference var and in the L94, this table calls;

https://github.com/rust-lang/rust-analyzer/blob/78c2bdce860dbd996a8083224d01a96660dd6a15/crates/hir-ty/src/infer/unify.rs#L364-L370

And while registering `AliasEq` `obligation`, this obligation contains inference var `?1` made from the previous table, but this table has only one inference var `?0` made at L365.
So, the chalk panics when we try to canonicalize that obligation to register it, because the obligation contains an inference var `?1` that the canonicalizing table doesn't have.

Currently, we are calling `InferenceTable::new()` to do some normalizing, unifying or coercing things to some targets that might contain inference var that the new table doesn't have.
I think that this is quite dangerous footgun because the inference var is just an index that does not contain the information which table does it made from, so sometimes this "foreign" index might cause panic like this case, or point at the wrong variable.

This PR mitigates such behaviour simply by inserting sufficient number of inference vars to new table to avoid such problem.
This strategy doesn't harm current r-a's intention because the inference vars that passed into new tables are just "unresolved" variables in current r-a, so this is just making sure that such "unresolved" variables exist in the new table

fix: Panic while hovering associated function with type annotation on generic param that not inherited from its container type

Fixes rust-lang#17871

We call `generic_args_sans_defaults` here;

https://github.com/rust-lang/rust-analyzer/blob/64a140527b383e3a2fe95908881624fc5374c60c/crates/hir-ty/src/display.rs#L1021-L1034

but the following substitution inside that function panic in rust-lang#17871;

https://github.com/rust-lang/rust-analyzer/blob/64a140527b383e3a2fe95908881624fc5374c60c/crates/hir-ty/src/display.rs#L1468

it's because the `Binders.binder` inside `default_parameters` has a same length with the generics of the function we are hovering on, but the generics of it is split into two, `fn_params` and `parent_params`.
Because of this, it may panic if the function has one or more default parameters and both `fn_params` and `parent_params` are non-empty, like the case in the title of this PR.

So, we must call `generic_args_sans_default` first and then split it into `fn_params` and `parent_params`

…kril

internal: Properly check the edition for edition dependent syntax kinds

This puts the current edition in a bunch of places, most of which I annoted with FIXMEs asside from the ones in ide-assists because I couldnt bother with those

Assuming it isn't cancelled. Closes rust-lang#17902.

The only place CommandHandle::join is used is when the flycheck command
finishes, so this commit changes the behavior of the method itself.

…zyCell/Lock

This doesn't get rid of the once_cell dependency, unfortunately, since we have dependencies that use it, but it's a nice to do cleanup. And when our deps will eventually get rid of once_cell we will get rid of it for free.

This speeds up short identifiers search significantly, while unlikely to have an effect on long identifiers (the analysis takes much longer than some character comparison).

Tested by finding all references to `eq()` (from `PartialEq`) in the rust-analyzer repo. Total time went down from 100s to 10s (a 10x reduction!).

internal: Replace once_cell with std's recently stabilized OnceCell/Lock and LazyCell/Lock

This doesn't get rid of the once_cell dependency, unfortunately, since we have dependencies that use it, but it's a nice to do cleanup. And when our deps will eventually get rid of once_cell we will get rid of it for free.

…s, r=Veykril

Test for word boundary in `FindUsages`

This speeds up short identifiers search significantly, while unlikely to have an effect on long identifiers (the analysis takes much longer than some character comparison).

Tested by finding all references to `eq()` (from `PartialEq`) in the rust-analyzer repo. Total time went down from 100s to 10s (a 10x reduction!).

Feel free to close this if you consider this a non-issue, as most short identifiers are local.

Allow flycheck process to exit gracefully

Assuming it isn't cancelled. Closes rust-lang#17902.

The only place CommandHandle::join() is used is when the flycheck command
finishes, so this commit changes the behavior of the method itself.

The only reason I can see for the existing behavior is if the command is somehow holding onto a build lock longer than it should, this would force it to be released. But it would be a pretty heavy-handed way to solve that issue. I'm not aware of this occurring in practice.

Implement lifetime inferring

This PR touches a lot of parts. But the main changes are changing
`hir_expand::Name` to be raw edition-dependently and only when necessary
(unrelated to how the user originally wrote the identifier),
and changing `is_keyword()` and `is_raw_identifier()` to be edition-aware
(this was done in rust-lang#17896, but the FIXMEs were fixed here).

It is possible that I missed some cases, but most IDE parts should properly
escape (or not escape) identifiers now.

The rules of thumb are:

 - If we show the identifier to the user, its rawness should be determined
   by the edition of the edited crate. This is nice for IDE features,
   but really important for changes we insert to the source code.
 - For tests, I chose `Edition::CURRENT` (so we only have to (maybe) update
   tests when an edition becomes stable, to avoid churn).
 - For debugging tools (helper methods and logs), I used `Edition::LATEST`.

…-keyword, r=Veykril

fix: Properly account for editions in names

This PR touches a lot of parts. But the main changes are changing `hir_expand::Name` to be raw edition-dependently and only when necessary (unrelated to how the user originally wrote the identifier), and changing `is_keyword()` and `is_raw_identifier()` to be edition-aware (this was done in rust-lang#17896, but the FIXMEs were fixed here).

It is possible that I missed some cases, but most IDE parts should properly escape (or not escape) identifiers now.

The rules of thumb are:

 - If we show the identifier to the user, its rawness should be determined by the edition of the edited crate. This is nice for IDE features, but really important for changes we insert to the source code.
 - For tests, I chose `Edition::CURRENT` (so we only have to (maybe) update tests when an edition becomes stable, to avoid churn).
 - For debugging tools (helper methods and logs), I used `Edition::LATEST`.

Reviewing notes:

This is a really big PR but most of it is mechanical translation. I changed `Name` displayers to require an edition, and followed the compiler errors. Most methods just propagate the edition requirement. The interesting cases are mostly in `ide-assists`, as sometimes the correct crate to fetch the edition from requires awareness (there may be two). `ide-completions` and `ide-diagnostics` were solved pretty easily by introducing an edition field to their context. `ide` contains many features, for most of them it was propagated to the top level function and there the edition was fetched based on the file.

I also fixed all FIXMEs from rust-lang#17896. Some required introducing an edition parameter (usually not for many methods after the changes to `Name`), some were changed to a new method `is_any_identifier()` because they really want any possible keyword.

Fixes rust-lang#17895.
Fixes rust-lang#17774.

…r=davidbarsky

Add scip/lsif flag to exclude vendored libaries

rust-lang#17809 changed StaticIndex to include vendored libraries. This PR adds a flag to disable that behavior.

At work, our monorepo has too many rust targets to index all at once, so we split them up into several shards. Since all of our libraries are vendored, if rust-analyzer includes them, sharding no longer has much benefit, because every shard will have to index the entire transitive dependency graphs of all of its targets. We get around the issue presented in rust-lang#17809 because some other shard will index the libraries directly.

…, r=lnicola

Remove rust-analyzer.workspace.discoverProjectRunner

The functionality for this vscode config option was removed in rust-lang#17395, so it doesn't do anything anymore.

Pin `rowan` to `0.15.15`

To prevent rust-lang#17914, I think that it would be safer pinning this before we fix it correctly

…t generics

fix: Wrong BoundVar index when lowering impl trait parameter of parent generics

Fixes rust-lang#17711

From the following test code;

```rust
//- minicore: deref
use core::ops::Deref;

struct Struct<'a, T>(&'a T);

trait Trait {}

impl<'a, T: Deref<Target = impl Trait>> Struct<'a, T> {
    fn foo(&self) -> &Self { self }

    fn bar(&self) {
        let _ = self.foo();
    }

}
```

when we call `register_obligations_for_call` for `let _ = self.foo();`,

https://github.com/rust-lang/rust-analyzer/blob/07659783fdfd4ec0a0bffa93017e33e31e567e42/crates/hir-ty/src/infer/expr.rs#L1939-L1952

we are querying `generic_predicates` and it has `T: Deref<Target = impl Trait>` predicate from the parent `impl Struct`;

https://github.com/rust-lang/rust-analyzer/blob/07659783fdfd4ec0a0bffa93017e33e31e567e42/crates/hir-ty/src/lower.rs#L375-L399

but as we can see above, lowering `TypeRef = impl Trait` doesn't take into account the parent generic parameters, so the `BoundVar` index here is `0`, as `fn foo` has no generic args other than parent's,

But this `BoundVar` is pointing at `'a` in `<'a, T: Deref<Target = impl Trait>>`.
So, in the first code reference `register_obligations_for_call`'s L:1948 - `.substitute(Interner, parameters)`, we are substituting `'a` with `Ty`, not `Lifetime` and this makes panic inside the chalk.

This PR fixes this wrong `BoundVar` index in such cases

…ection

feat: Make rust-analyzer work partially when offline

Helps out with rust-lang/rust-analyzer#12499 a bit

Include generics when lowering extern type

Fixes rust-lang#17767

…ategy`

These flags were added to help rust-analyzer integrate with repos
requiring non-Cargo invocations. The consensus is that having two
independent settings are no longer needed. This change removes
`invocationLocation` in favor of `invocationStrategy` and changes
the internal representation of `InvocationStrategy::Once` to hold
the workspace root.

…r=Veykril

chore(config): remove `invocationLocation` in favor of `invocationStrategy`

These flags were added to help rust-analyzer integrate with repos requiring non-Cargo invocations. The consensus is that having two independent settings are no longer needed. This change removes `invocationLocation` in favor of `invocationStrategy` and changes the internal representation of `InvocationStrategy::Once` to hold the workspace root.

Closes rust-lang#17848.

fix: keep comments in convert_while_to_loop

Fix rust-lang#17869.

minor: Improve documentation for `InvocationStrategy`

cc rust-lang/rust-analyzer#17888

fix: Panic when a TAIT exists in a RPIT

Fixes  rust-lang#17921

When there is a TAIT inside of a RPIT like;

```rust
trait Foo {}
type Bar = impl Foo;
fn foo<A>() -> impl Future<Output = Bar> { .. }
```

while inferencing `fn foo`, `insert_inference_vars_for_impl_trait` tries to substitute impl trait bounds of `Bar`, i.e. `Implemented(Foo)` with RPITs `placeholders`, and this causes panic

https://github.com/rust-lang/rust-analyzer/blob/fa003262474185fd62168379500fe906b331824b/crates/hir-ty/src/infer.rs#L903-L905

Priming caches is a performance win, but it takes a lock on the salsa
database and prevents rust-analyzer from responding to e.g. go-to-def
requests.

This causes confusion for users, who see the spinner next to
rust-analyzer in the VS Code footer stop, so they start attempting to
navigate their code.

Instead, set the `quiescent` status in LSP to false during cache
priming, so the VS Code spinner persists until we can respond to any
LSP request.

…kril

internal: ServerStatusParams should consider 'prime caches' in quiescent status

Priming caches is a performance win, but it takes a lock on the salsa database and prevents rust-analyzer from responding to e.g. go-to-def requests.

This causes confusion for users, who see the spinner next to rust-analyzer in the VS Code footer stop, so they start attempting to navigate their code.

Instead, set the `quiescent` status in LSP to false during cache priming, so the VS Code spinner persists until we can respond to any LSP request.

…r=Veykril

fix: Fix panics for semantic highlighting at startup

Without this we might try to process semantic highlighting requests before the database has entries for the given file resulting in a panic. There is no work to be done either way so delay this like we do with other request handlers.

Remove the ability to configure the user config path

Being able to do this makes little sense as this is effectively a cyclic dependency (and we do not want to fixpoint this really).

…ektas

fix: Add workspace level config to ratoml

fix: Wrong `Sized` predicate for `generic_predicates_for_param`

I found this gathers wrong `Self: Sized` bound while implementing object safety, though I couldn't find proper test for this.

If we call `generic_predicates_for_param` to `Bar` in the following code;
```rust
trait Foo<T: ?Sized> {}
trait Bar<T: Foo<Self> + ?Sized> {}
```
it returns `T: Sized` and `Self: Sized` bound, because normaly, the `?Sized` bound applied properly in L1059 with;
https://github.com/rust-lang/rust-analyzer/blob/3723e5910c14f0ffbd13de474b8a8fcc74db04ce/crates/hir-ty/src/lower.rs#L1035-L1061

But we filter them before it is lowered with that function here;

https://github.com/rust-lang/rust-analyzer/blob/3723e5910c14f0ffbd13de474b8a8fcc74db04ce/crates/hir-ty/src/lower.rs#L1540-L1586

So, the `?Sized` bounded params are not gathered into `ctx.unsized_types` and thus we are applying them implicit `Sized` bound here;

https://github.com/rust-lang/rust-analyzer/blob/3723e5910c14f0ffbd13de474b8a8fcc74db04ce/crates/hir-ty/src/lower.rs#L1591-L1602

Implement floating point casts in const eval

fix rust-lang#17926

internal: Improve macro token mapping heuristics

Fixes rust-lang/rust-analyzer#16235

…stic

fix: Improve proc-macro panic message and workspace loading failure diagnostic

… to - i.e. if we are inside a macro call

This avoids the need to analyze the file when we are not inside a macro call.

This is especially important for the optimization in the next commit(s), as there the common case will be to descent into macros but then not analyze.

…n identifiers such as `new`

The search is used by IDE features such as rename and find all references.

The search is slow because we need to verify each candidate, and that requires analyzing it; the key to speeding it up is to avoid the analysis where possible.

I did that with a bunch of tricks that exploits knowledge about the language and its possibilities. The first key insight is that associated methods may only be referenced in the form `ContainerName::func_name` (parentheses are not necessary!) (Rust doesn't include a way to `use Container::func_name`, and even if it will in the future most usages are likely to stay in that form.

Searching for `::` will help only a bit, but searching for `Container` can help considerably, since it is very rare that there will be two identical instances of both a container and a method of it.

However, things are not as simple as they sound. In Rust a container can be aliased in multiple ways, and even aliased from different files/modules. If we will try to resolve the alias, we will lose any gain from the textual search (although very common method names such as `new` will still benefit, most will suffer because there are more instances of a container name than its associated item).

This is where the key trick enters the picture. The key insight is that there is still a textual property: a container namer cannot be aliased, unless its name is mentioned in the alias declaration, or a name of alias of it is mentioned in the alias declaration.

This becomes a fixpoint algorithm: we expand our list of aliases as we collect more and more (possible) aliases, until we eventually reach a fixpoint. A fixpoint is not guaranteed (and we do have guards for the rare cases where it does not happen), but it is almost so: most types have very few aliases, if at all.

We do use some semantic information while analyzing aliases. It's a balance: too much semantic analysis, and the search will become slow. But too few of it, and we will bring many incorrect aliases to our list, and risk it expands and expands and never reach a fixpoint. At the end, based on benchmarks, it seems worth to do a lot to avoid adding an alias (but not too much), while it is worth to do a lot to avoid the need to semantically analyze func_name matches (but again, not too much).

After we collected our list of aliases, we filter matches based on this list. Only if a match can be real, we do semantic analysis for it.

The results are promising: searching for all references on `new()` in `base-db` in the rust-analyzer repository, which previously took around 60 seconds, now takes as least as two seconds and a half (roughly), while searching for `Vec::new()`, almost an upper bound to how much a symbol can be used, that used to take 7-9 minutes(!) now completes in 100-120 seconds, and with less than half of non-verified results (aka. false positives).

This is the less strictly correct (but faster) of this patch; it can miss some (rare) cases (there is a test for that - `goto_ref_on_short_associated_function_complicated_type_magic_can_confuse_our_logic()`). There is another branch that have no false negatives but is slower to search (`Vec::new()` never reaches a fixpoint in aliases collection there). I believe it is possible to create a strategy that will have the best of both worlds, but it will involve significant complexity and I didn't bother, especially considering that in the vast majority of the searches the other branch will be more than enough. But all in all, I decided to bring this branch (of course if the maintainers will agree), since our search is already not 100% accurate (it misses macros), and I believe there is value in the additional perf.

…ykril

fix: run flycheck without rev_deps when target is specified

Since querying for a crate's target is a call to salsa and therefore blocking, flycheck task is now deferred out of main thread by using `GlobalState`s `deferred_task_queue`. Fixes rust-lang#17829  and rust-lang/rustlings#2071

…=Veykril

perf: Speed up search for short associated functions, especially very common identifiers such as `new`

`@Veykril` said in rust-lang/rust-analyzer#17908 (comment) that people complain searches for `new()` are slow (they are right), so here I am to help!

The search is used by IDE features such as rename and find all references.

The search is slow because we need to verify each candidate, and that requires analyzing it; the key to speeding it up is to avoid the analysis where possible.

I did that with a bunch of tricks that exploits knowledge about the language and its possibilities. The first key insight is that associated methods may only be referenced in the form `ContainerName::func_name` (parentheses are not necessary!) (Rust doesn't include a way to `use Container::func_name`, and even if it will in the future most usages are likely to stay in that form.

Searching for `::` will help only a bit, but searching for `Container` can help considerably, since it is very rare that there will be two identical instances of both a container and a method of it.

However, things are not as simple as they sound. In Rust a container can be aliased in multiple ways, and even aliased from different files/modules. If we will try to resolve the alias, we will lose any gain from the textual search (although very common method names such as `new` will still benefit, most will suffer because there are more instances of a container name than its associated item).

This is where the key trick enters the picture. The key insight is that there is still a textual property: a container namer cannot be aliased, unless its name is mentioned in the alias declaration, or a name of alias of it is mentioned in the alias declaration.

This becomes a fixpoint algorithm: we expand our list of aliases as we collect more and more (possible) aliases, until we eventually reach a fixpoint. A fixpoint is not guaranteed (and we do have guards for the rare cases where it does not happen), but it is almost so: most types have very few aliases, if at all.

We do use some semantic information while analyzing aliases. It's a balance: too much semantic analysis, and the search will become slow. But too few of it, and we will bring many incorrect aliases to our list, and risk it expands and expands and never reach a fixpoint. At the end, based on benchmarks, it seems worth to do a lot to avoid adding an alias (but not too much), while it is worth to do a lot to avoid the need to semantically analyze func_name matches (but again, not too much).

After we collected our list of aliases, we filter matches based on this list. Only if a match can be real, we do semantic analysis for it.

The results are promising: searching for all references on `new()` in `base-db` in the rust-analyzer repository, which previously took around 60 seconds, now takes as least as two seconds and a half (roughly), while searching for `Vec::new()`, almost an upper bound to how much a symbol can be used, that used to take 7-9 minutes(!) now completes in 100-120 seconds, and with less than half of non-verified results (aka. false positives).

This is the less strictly correct (but faster) branch of this patch; it can miss some (rare) cases (there is a test for that - `goto_ref_on_short_associated_function_complicated_type_magic_can_confuse_our_logic()`). There is another branch that have no false negatives but is slower to search (`Vec::new()` never reaches a fixpoint in aliases collection there). I believe it is possible to create a strategy that will have the best of both worlds, but it will involve significant complexity and I didn't bother, especially considering that in the vast majority of the searches the other branch will be more than enough. But all in all, I decided to bring this branch (of course if the maintainers will agree), since our search is already not 100% accurate (it misses macros), and I believe there is value in the additional perf.

You can find the strict branch at https://github.com/ChayimFriedman2/rust-analyzer/tree/speedup-new-usages-strict.

Should fix rust-lang#7404, I guess (will check now).

feat: Implement `module_path` macro

Turns out this is a pain to implement because of our hir-def hir-expand split :)

internal: Don't requery crates_for for flycheck when crates are known

…p, r=Veykril

feat: Allow declaring cfg groups in rust-project.json, to help sharing common cfgs

Closes rust-lang#17815.

…kril

fix: Wrong `Self: Sized` predicate for trait assoc items

Again while implementing object safety like rust-lang#17939 😅

If we call `generic_predicates_query` on `fn foo` in the following code;
```
trait Foo {
    fn foo();
}
```
It returns implicit bound `Self: Sized`, even though `Self` is not appearing as a generic parameter inside angle brackets, but as a parent generic parameter, "trait self".

This PR prevent pushing "implicit" `Self: Sized` predicates in such cases

…s, r=lnicola

fix: rust-analyzer should watch build files from rust-project.json

rust-analyzer always watches Cargo.toml for changes, but other build systems using rust-project.json have their own build files.

Ensure we also watch those for changes, so we know when to reconfigure rust-analyzer when dependencies change.

Also create a test infrastructure for capture computation.

This is important for the "convert closure to fn" assist, as it needs to find and modify the places the captures are used.

We don't yet lower or maybe even parse them, but blocks already have `gen`, so why not.

Previously we were ignoring them.

This will be needed as we parse unknown identifiers and want to insert them into source code.

We can impl PartialOrd and Ord too, but I didn't need that.

… a search scope is set

In most places where we set a search scope it is a single file, and so the fast path will actually harm performance, since it has to search for aliases in the whole project.
The only exception that qualifies for the fast path is SSR (there is an exception that don't qualify for the fast path as it search for `use` items). It sets the search scope to avoid dependencies. We could make it use the fast path, but I didn't bother.

…scope, r=Veykril

fix: Don't enable the search fast path for short associated functions when a search scope is set

In most places where we set a search scope it is a single file, and so the fast path will actually harm performance, since it has to search for aliases in the whole project. The only exception that qualifies for the fast path is SSR (there is an exception that don't qualify for the fast path as it search for `use` items). It sets the search scope to avoid dependencies. We could make it use the fast path, but I didn't bother.

I forgot this while working on rust-lang#17927.