fix: local items should not be completed in parent signature
fixes#11959
> We get a Bar completion for the following snippet which is wrong as the item is not visible in that position.
> ``` rust
> fn foo() -> $0 {
> struct Bar;
> }
> ```
I investigated the problem and found that the scope of the cursor offset, also `CompletionContext.scope` is the body of the function
fix methods in pub trait generated by macro cannot be completed
Fix#12483
Check if the container is trait and inherit the visibility to associate items during collection.
fix: Pass the build data to rustc_private crates
With this all proc-macros should resolve in rustc now when setting up the build script running command properly.
fix: #12441 False-positive type-mismatch error with generic future
I think the reason is same with #11815.
add ```Sized``` bound for ```AsyncBlockTypeImplTrait```.
Order auto-imports by relevance
Fixes#10337.
Basically we sort the imports according to how "far away" the imported item is from where we want to import it to. This change makes it so that imports from the current crate are sorted before any third-party crates. Additionally, we make an exception for builtin crates (`std`, `core`, etc.) so that they are sorted before any third-party crates.
There are probably other heuristics that should be added to improve the experience (such as preferring imports that are common elsewhere in the same crate, and ranking crates depending on the dependency graph). However, I think this is a first good step.
PS. This is my first time contributing here, so please be gentle if I have missed something obvious :-)
feature: `Merge imports` assist can merge multiple selected imports.
The selected imports have to have a common prefix in paths.
Select imports or use trees to merge:
```rust
$0use std::fmt::Display;
use std::fmt::Debug;
use std::fmt::Write;$0
```
Apply `Merge imports`:
```rust
use std::fmt::{Display, Debug, Write};
```
Closes#12426
The selected imports have to have a common prefix in paths.
Before
```rust
$0use std::fmt::Display;
use std::fmt::Debug;$0
```
After
```rust
use std::fmt::{Display, Debug};
```
fix(extract_module) resolving import panics and improve import resolution
- Should solve #11766
- While adding a test case for this issue, I observed another issue:
For this test case:
```rust
mod x {
pub struct Foo;
pub struct Bar;
}
use x::{Bar, Foo};
$0type A = (Foo, Bar);$0
```
extract module should yield this:
```rust
mod x {
pub struct Foo;
pub struct Bar;
}
use x::{};
mod modname {
use super:❌:Bar;
use super:❌:Foo;
pub(crate) type A = (Foo, Bar);
}
```
instead it gave:
```rust
mod x {
pub struct Foo;
pub struct Bar;
}
use x::{};
mod modname {
use x::Bar;
use x::Foo;
pub(crate) type A = (Foo, Bar);
}
```
So fixed this problem with second commit
fix(ide-db): correct single-file module rename
Fixes a bug where rust-analyzer would emit `WorkspaceEdit`s with paths to dirs instead of files for the following project layout.
lib.rs
```rust
mod foo;
```
foo.rs
```rust
mod bar {
struct Bar;
}
```
Also fixes emitted paths for modules with mod.rs.
The bug resulted in panic in helix editor when attempting to rename a module.
fix: Retrigger visibility completion after parentheses
close#12390
This PR add `(` to trigger_characters as discussed in original issue.
Some questions:
1. Is lsp's `ctx.trigger_character` from `params.context` is the same as `ctx.original_token` inside actually completions?
1. If not what's the difference?
2. if they are the same, it's unnecessary to pass it down from handler at all.
3. if they are the same, maybe we could parse it from fixture directly instead of using the `check_with_trigger_character` I added.
2. Some completion fixtures written as `($0)` ( https://github.com/rust-lang/rust-analyzer/blob/master/crates/ide-completion/src/tests/fn_param.rs#L105 as an example), If I understand correctly they are not invoked outside tests at all?
1. using `ctx.original_token` directly would break these tests as well as parsing trigger_character from fixture for now.
2. I think it make sense to allow `(` triggering these cases?
3. I hope this line up with #12144
make `files.excludeDirs` work
There's a small issue because if all projects are excluded, this: 01d412f4d7/crates/rust-analyzer/src/main_loop.rs (L114) will be shown.
I thought about not showing it if `files.excludeDirs` is set, but that is not necessarily correct.
Fixes#7755
Fix inference when pattern matching a tuple field with a wildcard
This should fix the following issue: https://github.com/rust-lang/rust-analyzer/issues/12331
* Replaced the `err_ty` in `infer_pat()` with a new type variable.
* Had to change the iterator code a bit, to get around multiple mutable borrows of `self` in `infer_pat()`.
Also added a test
* Also added a test
Generate enum variant assist
So, this is kind of a weird PR!
I'm a complete newcomer to the `rust-analyzer` codebase, and so I browsed the "good first issue" tag, and found #11635. Then I found two separate folks had taken stabs at it, most recently `@maartenflippo` — and there had been a review 3 days ago, but no activity in a little while, and the PR needed to be rebased since the crates were renamed from `snake_case` to `kebab-case`.
So to get acquainted with the codebase I typed this PR by hand, looking at the diff in #11995, and I also added a doc-test (that passes).
I haven't taken into account the comments `@Veykril` left in #11995, but I don't want to steal any of `@maartenflippo's` thunder! Closing this PR is perfectly fine. Or Maarten could use it as a "restart point"? Or I could finish it up, whichever feels best to everyone.
I think what remains to be done in this PR, at least, is:
* [x] Only disable the "generate function" assist if the name is `PascalCase`
* [x] Only enable the "generate variant" assistant if the name is `PascalCase`
* [x] Simplify with `adt.source()` as mentioned here: https://github.com/rust-lang/rust-analyzer/pull/11995#discussion_r875134175
* [ ] Add more tests for edge cases? Are there cases where simply adding one more indent level than the enum's indent level is not good enough? Some nested trickery I'm not thinking of right now?
Anyway. This PR can go in any direction. You can tell me "no, tackle your own issue!" And I'll go do that and still be happy I got to take a look at rust-analyzer some by doing this. Or you can tell me "okay, now _you_ finish it", and I guess I'll try and finish it :)
Closes#11635
Increase defalt chalk overflow depth to match max solver size
TBC:
- #12279: ok above 480
- ~~#12182~~
- ~~#12095~~
- #11902: ok above 350
- ~~#11668~~
- #11370: ok above 450
- #9754: probably ok above 250 (!), and the code in cause and branch are gone
Closes#12279Closes#11902Closes#11370Closes#9754
Only advertise this feature in the server capabilities when the client
supports SnippetTextEdit.
Close#11398.
Co-authored-by: unexge <unexge@gmail.com>
This also disables "generate function" when what we clearly want is to
generate an enum variant.
Co-authored-by: Maarten Flippo <maartenflippo@outlook.com>
feat: Revert the "Add attribute" assist
Reverts https://github.com/rust-lang/rust-analyzer/pull/12296, as the added indirection and "assist noise" (the assist has to trigger inside the body of an item to match what the "Add `#[derive]`" does) makes this not really pull its weight over just using attribute completions.
Keeps the changes to "Add getter". `#[must_use]` can be applied using the attribute completions.
feat: hide type inlay hints for initializations of closures
This PR adds an option to hide the inlay hints for `let IDENT_PAT = CLOSURE_EXPR;`, which is a somewhat common coding pattern. Currently the inlay hints for the assigned variable and the closure expression itself are both displayed, making it rather repetitive.
In order to be consistent with closure return type hints, only closures with block bodies will be hid by this option.
Personally I'd feel comfortable making it always enabled (or at least when closure return type hints are enabled), but considering the precedent set in #10761, I introduced an off-by-default option for this.
changelog feature: option to hide type inlay hints for initializations of closures
