fix: Fix runnables being incorrectly constructed
I've misunderstood parts of the code here which caused runnables to arbitrarily break :) (I have yet to understand the conditions that made them break though, there is some odd caching involved I feel like ...)
Fixes https://github.com/rust-lang/rust-analyzer/issues/17402
internal: Clean up runnable lsp extension
This feels like a natural addition to me, and also allows us to drop the expect-test hardcoding from the extension. Additionally, `cargoExtraArgs` is pointless, all the client will do is merge it with `cargoArgs` so the server can do that instead of delegating that to the client.
Disallow nested impl traits
Fixes#17498
The above issue is due to formatting self referencing, recursive bound like `Implemented(^0.0: TraitId(0)<[?0 := ^0.0]>)` on the codes like;
```rust
trait Foo<T> {}
trait Bar {}
fn test(foo: impl Foo<impl Bar>) { ... }
```
When lowering predicate `impl Foo<impl Bar>` in `trait_environment_query`, the outer `impl Foo<...>` is treated as predicates, so the first `TypeRef` that passes the following code is `impl Bar`;
cae997e338/crates/hir-ty/src/lower.rs (L376-L400)
and thus the `idx` is `0` in the above context.
But the following code sets `self_ty` as the `BoundVar` with `idx = 0` because the target param id for predicate `impl Foo<...>` is `0` since `impl Foo` is the first generic-like parameter of `fn test`;
cae997e338/crates/hir-ty/src/lower.rs (L998-L1025)
For the codes like;
```rust
trait Foo {
type Assoc;
}
trait Bar {}
fn test(foo: impl Foo<Assoc = impl Bar>) { ... }
```
similar recursive bound doesn't happen because the following codes ***"count the number of `impl Trait` things that appear before the target of our `bound`."***
cae997e338/crates/hir-ty/src/lower.rs (L1168-L1199)
Instead of doing similar thing like nested `impl Foo<impl Bar>` thing, this PR lowers such nested impl traits into error types in the similar manner as the rustc does in the following lines (and of course, allows lowering and inferencing nested impl traits for the cases that rustc permits);
- e2cf31a614/compiler/rustc_ast_passes/src/ast_validation.rs (L802-L813)
- 7b21c18fe4/compiler/rustc_ast_passes/src/ast_validation.rs (L1299-L1314)
(Though rustc emits [E0666😈](https://doc.rust-lang.org/error_codes/E0666.html), I skipped diagnostics since gathering diagnostics in `hir-def` has no conventions so far 😅)
fix: Don't emit semantic diagnostics in files with a lot of syntax errors
These will only add to the noise when something very unexpected breaks or where parser recovery fails to kick in.
fix: Skip match exhaustiveness checking if pattern type contains errors
Should fix https://github.com/rust-lang/rust-analyzer/issues/17509, checking when errors are involved is generally a bad idea as the algorithm doesn't really expect error types in the first place I believe
do not normalize `use foo::{self}` to `use foo`
It changes behaviour and can cause collisions. E.g. for the following snippet
```rs
mod foo {
pub mod bar {}
pub const bar: i32 = 8;
}
// transforming the below to `use foo::bar;` causes the error:
//
// the name `bar` is defined multiple times
use foo::bar::{self};
const bar: u32 = 99;
fn main() {
let local_bar = bar;
}
```
we still normalize
```rs
use foo::bar;
use foo::bar::{self};
```
to `use foo::bar;` because this cannot cause collisions.
See: https://github.com/rust-lang/rust-analyzer/pull/17140#issuecomment-2079189725
