Use proper `ImplTraits` in `insert_inference_vars_for_impl_trait`
Fixes#17199 and fixes#17403
In the previous implementation, I passed `rpits` as a function parameter and used `idx` of `ImplTraitId` for indexing `ImplTrait`.
4e836c622a/crates/hir-ty/src/infer.rs (L881-L887)
But that `idx` is rather a "local" one, so in the cases like mentioned issues, the async function that can be expanded roughly as
```rust
type TypeAlias = impl Something;
fn expanded_async() -> impl Future<Output = TypeAlias> { ... }
```
there are two bundles of `ImplTraits`; one for the `impl Future` and the other one for `TypeAlias`.
So using `idx` with `rpits` returns `ImplTrait` for `impl Future` even if we are asking for `TypeAlias` and this caused a stack overflow.
This PR is a fix for that implementation miss 😅
minor: Bump `actions/download-artifact` and `upload-artifact`
These will stop working in a couple of days. I think we could still use them in a more efficient way, but more tweaking is needed for that.
minor : Fix duplicate snippets showing up on hover.
With each `config::apply_change` duplicate configs were being added.
Now we first drain the vec that holds these and then start adding. This fixes#17485
internal: Some more small memory optimizations
Not a big impact on metrics, though there are some more savings in queries mainly used by the IDE layer from this
fix: Improve hover text in unlinked file diagnostics
Use full sentences, and mention how to disable the diagnostic if users are intentionally working on unowned files.
![Screenshot 2024-06-12 at 5 55 48 PM](https://github.com/rust-lang/rust-analyzer/assets/70800/c91ee1ed-1c72-495a-9ee3-9e360a5c6977)
(Full disclosure: I've tested a rust-analyzer build in VS Code, but the pop-up logic is currently disabled due to #17062, so I haven't tested that.)
fix: pattern completions in let-stmt
fix#17480.
We can write `let S { a, b } = s;` or `let Some(x) = a else {}`, so it is reasonable to allow pattern completions in `LetStmt`.
Simplify some term search tactics
Working on the paper `@phijor` found that "Data constructor" tactic could be simplified quite a bit by running it only in the backwards direction. With n+1 rounds it has same coverage as previous implementation in n rounds, however the tactic it self is more simple and also potentially faster as there is less to do.
In a nutshell the idea is to only work with types in the wish-list rather than with any types.
Turns out it is quite a bit faster:
Before:
```
ripgrep:
Tail Expr syntactic hits: 238/1692 (14%)
Tail Exprs found: 1223/1692 (72%)
Term search avg time: 15ms
nalgebra:
Tail Expr syntactic hits: 125/3001 (4%)
Tail Exprs found: 2143/3001 (71%)
Term search avg time: 849ms
```
After
````
ripgrep:
Tail Expr syntactic hits: 246/1692 (14%)
Tail Exprs found: 1209/1692 (71%)
Term search avg time: 8ms
nalgebra:
Tail Expr syntactic hits: 125/3001 (4%)
Tail Exprs found: 2028/3001 (67%)
Term search avg time: 305ms
````
_Also removed niche optimization of removing scope defs from the search space as this wasn't helping much anyway and made code a bit more complex._
fix: use ItemInNs::Macros to convert ModuleItem to ItemInNs
fix#17425.
When converting `PathResolution` to `ItemInNs`, we should convert `ModuleDef::Macro` to `ItemInNs::Macros` to ensure that it can be found in `DefMap`.