diff options
author | bors[bot] <26634292+bors[bot]@users.noreply.github.com> | 2021-03-16 07:57:33 +0000 |
---|---|---|
committer | GitHub <[email protected]> | 2021-03-16 07:57:33 +0000 |
commit | 62ec04bbd53ba50e21a7b8f23d46958d322640eb (patch) | |
tree | 64e76e782e6befe998907e631e125ea1b7a27475 /crates/syntax/test_data/parser/fragments/pattern/err | |
parent | 5fa26d05fb5041c4061ee484e12453aa6e465fa7 (diff) | |
parent | 405bbb3aa46ecbfa5124969739695565d9841b9c (diff) | |
parent | 30dea3a727879f9ed6cfe06433f1adb51765fa9e (diff) |
Merge #8036 #8046
8036: completions: provide relevance bonus for enum types, and suggest ref matches for fn and enum r=matklad a=JoshMcguigan
This PR makes several improvements to completions and completion sorting:
1. Provide exact match type relevance score bonus for enum variants
2. Suggest `&Foo` (ref_match) for enums if that is an exact type match
3. Suggest `&foo()` (ref_match) if `foo` returns a type which would be an exact match either with the reference or due to a `Deref` impl
### Before
![pre-ref-relevance-centralized](https://user-images.githubusercontent.com/22216761/111189377-3f05a580-8573-11eb-89be-58a45cb7f829.png)
### After
![post-ref-relevance-centralized](https://user-images.githubusercontent.com/22216761/111189395-45941d00-8573-11eb-871b-09186b35cbb9.png)
### Caveats
I think generic types will require some kind of fancier logic when testing for `exact_type_match`, so for now `Option`/`Result`/etc unfortunately still don't have great completions.
### Implementation
I implemented this in a way that I think makes it most likely for each completion type to be handled consistently. Just replace `CompletionItem::new` with `CompletionItem::new_with_type_info` and `exact_type_match`/`exact_name_match`/`ref_match` are all handled for you, in a way which is sure to be consistent across completion types.
This approach does introduce some coupling/plumbing that didn't exist before. Notice for example `set_is_local` on the builder, because `set_relevance` was removed from the builder to enforce that the relevance was built "properly" with `CompletionItem::new_with_type_info`. But I think there are benefits to this approach, like `CompletionRelevance` should probably consider deprecation status, and we already tell the builder about that, so in the (likely near term) future we can just pass that information along to `CompletionRelevance` when the user calls `set_deprecated` rather than the user having to manually set it in two places. This basically just hides `CompletionRelevance` from the individual completions, so they only worry about the `CompletionItem` interface. At the moment this seems like a cleaner approach to me, but I'm open to feedback here.
edit - I've reimplemented this in a simpler way, per feedback below.
8046: Prefer match to if let else r=matklad a=matklad
bors r+
🤖
Co-authored-by: Josh Mcguigan <[email protected]>
Co-authored-by: Aleksey Kladov <[email protected]>