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>
11802: fix: add stubs to make proc macros work that use the `SourceFile` API r=jonas-schievink a=jonas-schievink
Helps with the rocket 0.4 macros, at least on some Rust versions.
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/11264
bors r+
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
11805: fix: Don't try to resolve methods on unknown types r=Veykril a=flodiebold
Fixes#10454, and some type mismatches.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
11801: fix: avoid returning `None` from `Span::join` to fix some proc macros r=jonas-schievink a=jonas-schievink
Some proc macros, notably rocket, `.unwrap()` the result of `Span::join` (and correctly so, it should never be `None`). We don't have a proper implementation of that API, so we always returned `None`. This changes our stub impl to return the first span instead.
Does not fully fix rocket's macros, they need other stuff to work too.
bors r+
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
