6618: Properly infer tuple patterns when encountering ellipsis r=Veykril a=Veykril
We basically just split the subpatterns into two halves when the ellipsis is present and then offset the latter half to account for the ignored bindings.
Fixes#6616
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
6610: add 'Re-enable this test' assist r=SomeoneToIgnore a=jakobhellermann
The `Ignore this test` assist previously allowed ignoring multiple times, each time adding a `#[ignore]` attribute.
This PR instead shows an assist to undo the ignoring.
Co-authored-by: Jakob Hellermann <jakob.hellermann@protonmail.com>
6553: Auto imports in completion r=matklad a=SomeoneToIgnore
Closes https://github.com/rust-analyzer/rust-analyzer/issues/1062 but does not handle the completion order, since it's a separate task for https://github.com/rust-analyzer/rust-analyzer/issues/4922 , https://github.com/rust-analyzer/rust-analyzer/issues/4922 and maybe something else.
2 quirks in the current implementation:
* traits are not auto imported during method completion
If I understand the current situation right, we cannot search for traits by a **part** of a method name, we need a full name with correct case to get a trait for it.
* VSCode (?) autocompletion is not as rigid as in Intellij Rust as you can notice on the animation.
Intellij is able to refresh the completions on every new symbol added, yet VS Code does not query the completions on every symbol for me.
With a few debug prints placed in RA, I've observed the following behaviour: after the first set of completion suggestions is received, next symbol input does not trigger a server request, if the completions contain this symbol.
When more symbols added, the existing completion suggestions are filtered out until none are left and only then, on the next symbol it queries for completions.
It seems like the only alternative to get an updated set of results is to manually retrigger it with Esc and Ctrl + Space.
Despite the eerie latter bullet, the completion seems to work pretty fine and fast nontheless, but if you have any ideas on how to make it more smooth, I'll gladly try it out.
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
6544: add suggestion ..Default::default() for remaining struct fields in a constructor r=bnjjj a=bnjjj
I'm not sure I should import `assists` crate inside `completions`, maybe we should move out `FamousDefs` from `assists` ? Let me know :)
close#6492
Signed-off-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>
Co-authored-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>
6524: Add support for loading rustc private crates r=matklad a=xldenis
This PR presents a solution to the problem of making`rustc_private` crates visible to `rust-analyzer`.
Currently developers add dependencies to those crates behind a `cfg(NOT_A_TARGET)` target to prevent `cargo` from building them.
This solution is unsatisfactory since it requires modifying `Cargo.toml` and causes problems for collaboration or CI.
The proposed solution suggested by @matklad is to allow users to give RA a path where the `rustc` sources could be found and then load that like a normal workspace.
This PR implements this solution by adding a `rustcSource` configuration item and adding the cargo metadata to the crate graph if it is provided.
------
I have no idea how this should be tested, or if this code is generally tested at all. I've locally run the extension with these changes and it correctly loads the relevant crates on a `rustc_private` project of mine.
Co-authored-by: Xavier Denis <xldenis@gmail.com>
6514: Fix extract_struct_from_enum_variant not updating record references r=Veykril a=Veykril
Related to #6510
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
6513: Support qualified function calls in remove_unused_param r=Veykril a=Veykril
Also adds a test to check that it removes unused params across files.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
