11870: Recover from missing type annotation r=Veykril a=HKalbasi
We were missing the init expression in case of `let x: = 2`, which breaks type inference of that variable (previously x were `{unknown}`, now it is `i32`).
Co-authored-by: hkalbasi <hamidrezakalbasi@protonmail.com>
11871: internal: Move `rust.ungram` into `rust-analyzer/crates/syntax` r=Veykril a=Veykril
This makes updating the grammar a lot simpler for us. Though removing it from ungrammar can't be done without bumping it to 2.0 so I'll leave it in there for the time being.
cc https://github.com/rust-analyzer/ungrammar/pull/47
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
11867: create generate is, as, try_into group r=Veykril a=jakevossen5
Fixes#11636
In `generate_enum_projection_method.rs`, the changes to the function are from `cargo fmt`, I made the same change as I did in `generate_enum_is_method.rs`.
Co-authored-by: Jake Vossen <jake@vossen.dev>
11863: fix: allow varargs in any param position r=jonas-schievink a=jonas-schievink
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/3578 and aligns us with the Rust reference.
bors r+
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
11861: internal: Add "view file text" command to debug sync issues r=jonas-schievink a=jonas-schievink
I saw a file sync bug the other day but didn't know how to further debug it. This command might give a clue as to what's wrong and help debug issues like https://github.com/rust-analyzer/rust-analyzer/issues/4829.
bors r+
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
11852: Type mismatch when last expression is noreturn asm r=lnicola a=weirdsmiley
When last expression in a function body is noreturn asm, then analyzer
complains about the type mismatch by highlighting entire body. This
fixes it by introducing loop {} in the expanded code.
Fixes: [#11820](https://github.com/rust-analyzer/rust-analyzer/issues/11820)
Co-authored-by: Manas <manas18244@iiitd.ac.in>
When last expression in a function body is noreturn asm, then analyzer
complains about the type mismatch by highlighting entire body. This
fixes it by introducing loop {} in the expanded code.
11849: docs(auto_import): change by_self -> self and by_crate -> crate r=Veykril a=gibfahn
---
#### Commits _(oldest to newest)_
6b38c2d75 docs(auto_import): change by_self -> self and by_crate -> crate
Keep things consistent with the package.json , which uses `self` and
`crate` instead of `by_self` and `by_crate`. Both names are in fact
allowed as aliases, but we should be consistent so that people reading
the docs and using a schema do not see red squiggles.
<br/>
Co-authored-by: Gibson Fahnestock <gibfahn@gmail.com>
Keep things consistent with the package.json , which uses `self` and
`crate` instead of `by_self` and `by_crate`. Both names are in fact
allowed as aliases, but we should be consistent so that people reading
the docs and using a schema do not see red squiggles.
11844: Fix divergence detection for bare match arms r=flodiebold a=flodiebold
Fixes#11814 and #11837.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
11842: Fix duplicate type mismatches with blocks r=flodiebold a=flodiebold
E.g. when there's a type mismatch on the return value of a function. To fix this, we have to return the expected type as the type of the block when there's a mismatch. That meant some IDE code that expected otherwise had to be adapted, in particular the "add return type" assist. For the "wrap in Ok/Some" quickfix, this sadly means it usually can't be applied in all branches of an if expression at the same time anymore, because there's a type mismatch for each branch that has the wrong type.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
E.g. when there's a type mismatch on the return value of a function. To
fix this, we have to return the expected type as the type of the block
when there's a mismatch. That meant some IDE code that expected
otherwise had to be adapted, in particular the "add return type" assist.
For the "wrap in Ok/Some" quickfix, this sadly means it usually can't be applied
in all branches of an if expression at the same time anymore, because
there's a type mismatch for each branch that has the wrong type.
11840: Fix another const generic panic r=flodiebold a=HKalbasi
fix#11835
If I change `dyn` to `impl` in the test, it will infer the type as `IntoIterator::Item<impl Iterator<Item = [Ar<u8, 7>; 9]> + ?Sized>` instead of `[Ar<u8, 7>; 9]`. Maybe it needs some action?
Co-authored-by: hkalbasi <hamidrezakalbasi@protonmail.com>
11833: internal: Move mismatched arg count diagnostic to inference r=flodiebold a=flodiebold
This means we only need to handle legacy const generics in one place, and it fits there especially since there will be more diagnostics coming.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
11832: Fix typo in the style documentation r=lnicola a=Therzok
Was going through the documentation itself and found this typo just waiting to be fixed
Co-authored-by: Marius Ungureanu <therzok@gmail.com>
11831: fix: Disable ref_match for qualified paths as well r=flodiebold a=flodiebold
I.e. don't suggest `Foo::&foo()`.
CC #8058.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
11809: feat: disable experimental diagnostics by default r=jonas-schievink a=jonas-schievink
Now that we diagnose type mismatches, we have another diagnostic that can potentially produce false positives, so let's disable experimental diagnostics by default.
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
11810: internal: rename the 1.47 proc macro ABI to 1.48 r=jonas-schievink a=jonas-schievink
Closes https://github.com/rust-analyzer/rust-analyzer/issues/9898.
We don't support 1.47, so rename it to reflect that.
bors r+
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
11772: Support constants in const eval r=HKalbasi a=HKalbasi
This PR enables evaluating things like this:
```rust
const X: usize = 2;
const Y: usize = 3 + X; // = 5
```
My target was nalgebra's `U5`, `U22`, ... which are defined as `type U5 = Const<{ SomeType5::SOME_ASSOC_CONST }>` but I didn't find out how to find the `ConstId` of the implementation of the trait, not the trait itself (possibly related to #4558 ? We can find associated type alias, so maybe this is doable already) So it doesn't help for nalgebra currently, but it is useful anyway.
Co-authored-by: hkalbasi <hamidrezakalbasi@protonmail.com>
