user0/rust
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
my rust fork https://www.rust-lang.org
15548 commits 10 branches 154 tags 1.3 GiB
Find a file
bors[bot] 19dd1fd4d4
Merge #7904 
7904: Improved completion sorting r=JoshMcguigan a=JoshMcguigan

I was working on extending #3954 to apply completion scores in more places (I'll have another PR open for that soon) when I discovered that actually completion sorting was not working for me at all in `coc.nvim`. This led me down a bit of a rabbit hole of how coc and vs code each sort completion items.

Before this PR, rust-analyzer was setting the `sortText` field on completion items to `None` if we hadn't applied any completion score for that item, or to the label of the item with a leading whitespace character if we had applied any completion score. Completion score is defined in rust-analyzer as an enum with two variants, `TypeMatch` and `TypeAndNameMatch`. 

In vs code the above strategy works, because if `sortText` isn't set [they default it to the label](b4ead4ed66). However, coc [does not do this](e211e36147/src/completion/complete.ts (L245)).

I was going to file a bug report against coc, but I read the [LSP spec for the `sortText` field](https://microsoft.github.io/language-server-protocol/specifications/specification-current/#textDocument_completion) and I feel like it is ambiguous and coc could claim what they do is a valid interpretation of the spec.

Further, the existing rust-analyzer behavior of prepending a leading whitespace character for completion items with any completion score does not handle sorting `TypeAndNameMatch` completions above `TypeMatch` completions. They were both being treated the same.

The first change this PR makes is to set the `sortText` field to either "1" for `TypeAndNameMatch` completions, "2" for `TypeMatch` completions, or "3" for completions which are neither of those. This change works around the potential ambiguity in the LSP spec and fixes completion sorting for users of coc. It also allows `TypeAndNameMatch` items to be sorted above just `TypeMatch` items (of course both of these will be sorted above completion items without a score). 

The second change this PR makes is to use the actual completion scores for ref matches. The existing code ignored the actual score and always assumed these would be a high priority completion item.

#### Before

Here coc just sorts based on how close the items are in the file.

![image](https://user-images.githubusercontent.com/22216761/110249880-46063580-7f2d-11eb-9233-91a2bbd48238.png)

#### After

Here we correctly get `zzz` first, since that is both a type and name match. Then we get `ccc` which is just a type match.

![image](https://user-images.githubusercontent.com/22216761/110249883-4e5e7080-7f2d-11eb-9269-a3bc133fdee7.png)


Co-authored-by: Josh Mcguigan <joshmcg88@gmail.com>
2021-03-12 14:23:32 +00:00
.cargo Use lld on winsows 2020-08-19 20:17:49 +02:00
.github Delete old issues from GitHub's bug report template 2021-02-28 18:12:43 +03:00
.vscode Add "Win Attach to Server" debug configuration 2021-01-25 17:46:03 +03:00
assets Add SVG logos to assets directory 2020-08-28 21:41:45 +10:00
bench_data Add benchmark test for mbe 2021-02-25 05:47:13 +08:00
crates Merge #7904 2021-03-12 14:23:32 +00:00
docs Fix remaining references to cargo xtask codegen 2021-03-12 15:10:33 +01:00
editors/code Make code less surprising 2021-03-09 14:47:42 +03:00
lib ⬆️ arena 2021-01-17 11:43:04 +03:00
xtask Fix remaining references to cargo xtask codegen 2021-03-12 15:10:33 +01:00
.gitattributes Rename ra_syntax -> syntax 2020-08-12 18:30:53 +02:00
.gitignore add open Cargo.toml action 2020-11-12 17:48:07 -08:00
bors.toml Reduce bors timeout 2020-10-14 13:37:20 +02:00
Cargo.lock Use expect-test for builtin macro/derive tests 2021-03-10 21:05:02 +01:00
Cargo.toml Handle self/super/crate in PathSegment as NameRef 2021-01-15 19:21:23 +01:00
LICENSE-APACHE Licenses 2018-01-10 22:47:04 +03:00
LICENSE-MIT Licenses 2018-01-10 22:47:04 +03:00
PRIVACY.md Add notes concerning privacy and network access 2020-10-04 20:16:53 +03:00
README.md Directly link changelog from quick-links section in 'README.md' file 2021-02-28 13:20:05 +01:00
rustfmt.toml Remove forcing \n via rustfmt 2019-11-02 22:19:59 +03:00

README.md

rust-analyzer logo

rust-analyzer is an experimental modular compiler frontend for the Rust language. It is a part of a larger rls-2.0 effort to create excellent IDE support for Rust.

Work on rust-analyzer is sponsored by

Ferrous Systems

Quick Start

https://rust-analyzer.github.io/manual.html#installation

Documentation

If you want to contribute to rust-analyzer or are just curious about how things work under the hood, check the ./docs/dev folder.

If you want to use rust-analyzer's language server with your editor of choice, check the manual folder. It also contains some tips & tricks to help you be more productive when using rust-analyzer.

Communication

For usage and troubleshooting requests, please use "IDEs and Editors" category of the Rust forum:

https://users.rust-lang.org/c/ide/14

For questions about development and implementation, join rls-2.0 working group on Zulip:

https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Frls-2.2E0

Quick Links

License

Rust analyzer is primarily distributed under the terms of both the MIT license and the Apache License (Version 2.0).

See LICENSE-APACHE and LICENSE-MIT for details.