-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tracking issue for ide-completion
refactor
#12144
Labels
Comments
bors
added a commit
that referenced
this issue
May 5, 2022
internal: Lift out item list path completions from (un)qualified_path cc #12144
bors
added a commit
that referenced
this issue
May 5, 2022
internal: Lift out item list path completions from (un)qualified_path cc #12144
bors
added a commit
that referenced
this issue
May 5, 2022
internal: Remove `unqualified_path` completions module cc #12144
This was referenced May 23, 2022
bors
added a commit
that referenced
this issue
May 30, 2022
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
bors
added a commit
that referenced
this issue
Jun 3, 2022
internal: Clean up keyword completion handling #12144
With #12560 #12565 #12564 #12562 and #12573 the main refactors in this issue are now done. I've split the two other checkboxes into separate issues as htey are less of a refactoring task and more of an implementation thing, #12567 #12568 The last refactor we need to do now is #12571 and then we should have reached a state where we can perfect our completions on |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
In #11397 I started refactoring the completions crate a bit and I haven't gotten back to finishing this up, so the crate is in a weird state where we use 3 differnt things to determine where certain completions apply. So with this I'll write down what I had in mind and where we are currently at in regards to that plan.
Completions are generated by fist calculating a
CompletionContext
which analyzes the surrounding context of the cursor position which we can then derive the completions from. Following that we just execute a bunch of functions that fill the completions accumulator with completions.rust-analyzer/crates/ide-completion/src/lib.rs
Lines 150 to 173 in 0ee4e6a
The here was to have a function calculating completions for a specific "thing", this "thing" varies widely as to what it applies though. My goal with the refactor was to make this "thing" more consistent in what it covers.
We can group the things we actually complete into roughly the following:
Name
sLifetime
sNameRef
s (paths and a few exceptios)Obviously grouping the completion generation by just these is too rough, we want to do it differently. Completing by
Name
s andNameRef
s alone is messy, as we need to know about the context of where we are completing in (are we inside a type position, expression position, function return type, etc...), but this is what we kind of are doing right now if you take a look at the unqualified path module or the qualfied path module (these are practically theNameRef
case). There are a bunch of different checks regarding where we are currently at placed around at various places making the code a mess.So what I instead envision is for us to split these modules apart according to their position they apply to, with branches for the different thinsg that can be completed there (with a few exceptions for special completions). I've started with this for paths, where I have split out attributes, visibility paths, use paths and pattern paths.
This structure allows one to more easily reason about what completions apply where.
This refactor should get us closer to do "perfect completions".
I'll fully fill out the list of finer grained tasks here later this week:
unsafe const $0
we should only proposefn
, notconst
orunsafe
again.is_path_disallowed
and otherCompletionContext
functions that look like temporary hacks.The text was updated successfully, but these errors were encountered: