Our current completion test infra resovles around usually just checking a specific `CompletionKind` which is suboptimal. We only see what we want to see in tests with this causing us to miss a lot of incorrect completions we are doing. Instead we should test for different cursor locations for all kinds(sans the magic kind maybe? not sure yet). This way we will also see potential duplicate completions that merely different in their kind.
Also since most completion submodules complete things in tests of other modules due to the tests overlapping it makes more sense to group these tests differently which implies moving them to a new module. Exceptions for this might be stuff like attribute completion as these cannot currently interfere.
I only wrote a few tests to check for completions in `ItemList` position so far and I already found a few incorrect/irrelevant completions as these haven't been tested properly due to them being hidden by the `CompletionKind` filtering.
I think `CompletionKind` doesn't really seem to be beneficial to me as to I can't think of a occasion where we would want to only check a specific completion kind.
bors[bot] [Wed, 16 Jun 2021 14:53:06 +0000 (14:53 +0000)]
Merge #9258
9258: minor: Give `ImportPrefix` variants better config names r=matklad a=Veykril
I feel like `crate` and `self` work better than `by_crate` and `by_self`. The only reason for the current names were that `Self` doesn't work for the variant name on the rust side so I forgot about setting proper config names on serde layer.
bors[bot] [Tue, 15 Jun 2021 20:45:54 +0000 (20:45 +0000)]
Merge #9267 #9279
9267: fix: Code: update the LSP server without asking r=matklad a=lnicola
Most LSP extensions seem to do the same thing, and this is causing some
confusion for users who don't notice the update prompt before Code hides
it.
9279: minor: Document installation via Homebrew r=matklad a=Svetlitski
`rust-analyzer` can be installed via [Homebrew](https://brew.sh) (AKA`brew`) on macOS. I've added instructions on how to do so to the documentation. Additionally, I added a `.gitignore` rule to ignore the HTML documentation produced by `asciidoctor manual.adoc` so that it is not accidentally checked into `git`.
#8951 was a major change in the VS Code extension and caused quite a few problems. This PR is a catch-all for bugs and improvements in the new code.
This should fix:
- #9284
- [this unreported bug](https://github.com/rust-analyzer/rust-analyzer/pull/8951/files#r651570446)
- ...and one or two uncaught exceptions I just found
The original lack of testing was my own fault, but this area of the VS Code API is also tricky for a couple reasons:
- The [FileSystem](https://github.com/rust-analyzer/rust-analyzer/pull/8951/files#r651570446) API does not list or warn about any exceptions, but [FileSystemProvider](https://github.com/rust-analyzer/rust-analyzer/pull/8951/files#r651570446) (which `FileSystem` is a wrapper of, AFAICT) does.
- At first glance, [Uri.path](https://github.com/rust-analyzer/rust-analyzer/pull/8951/files#r651570446) *looks* like it works for FS operations. It does not, at least, on Windows. You need to use `Uri.fsPath`.
I only use Windows, so I need people on macOS, Linux, and (possibly) NixOS to test this.
Aleksey Kladov [Mon, 14 Jun 2021 14:19:41 +0000 (17:19 +0300)]
internal: prepare to move rename to base_db
It's better to handle magical cases upper in the stack, because it
allows for better re-use of the general implementation below. So, we
pull the `self` case up here.
The end goal is to put `Definition::rename` to the `ide_db`, because
it's a generally re-usable functionality useful for different ide
features, alongside with the search which is already there.
Aleksey Kladov [Mon, 14 Jun 2021 12:43:59 +0000 (15:43 +0300)]
fix: don't use display-related functionality where semantics matters
NavigationTarget is strictly a UI-level thing -- it describes where the
cursor should be placed when the user presses goto definition. It
doesn't make any semantic guaratees about rage and focus range and, as
such, is not suitable for driving renames.
bors[bot] [Mon, 14 Jun 2021 10:30:10 +0000 (10:30 +0000)]
Merge #8951
8951: internal: migrate to vscode.FileSystem API r=matklad a=wxb1ank
I encountered an error where `bootstrap()` attempts to create a directory with the path `C:\C:\...`. I couldn't find this reported anywhere else. Using the `vscode.FileSystem` API instead of the `fs` one works here. I assume the latter automatically prepends `C:\` to paths whereas the former does not. I don't know if this suggests `vscode.FileSystem` should be used in more places for consistency.