Previously, when line numbers of Rust spans were converted to LSP
ranges, they could underflow resulting in very large line numbers. As
an underflow is always wrong, prevent it and use 0 instead.
The logic for importing with and without `group_imports` differed
significantly when no previous group existed. This lead to the problem
of using the wrong position when importing inside a module (#11585) or
when inner attributes are involved.
The existing code for grouped imports is better and takes these things
into account.
This PR changes the flow to use the pre-existing code for adding a new
import group even for the non-grouped import settings.
Some coverage markers are updated and the `group` is removed, since they
are now invoked in both cases (grouping and no grouping).
Tests are updated and two tests (empty module and inner attribute) are
added.
Fixes#11585
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>
