Unfortunately I ran into https://github.com/rust-analyzer/rust-analyzer/issues/4058 while testing this on https://github.com/nrf-rs/nrf-hal/, so I didn't see much of it in action yet, but it does seem to work.
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com> Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
bors[bot] [Thu, 22 Oct 2020 20:46:24 +0000 (20:46 +0000)]
Merge #6098
6098: Insert ref for completions r=adamrk a=adamrk
Follow up to https://github.com/rust-analyzer/rust-analyzer/pull/5846. When we have a local in scope which needs a ref or mutable ref to match the name and type of the active in the completion context then a new completion item with `&` or `&mut ` is inserted. E.g.
```rust
fn foo(arg: &i32){};
fn main() {
let arg = 1_i32;
foo(a<|>)
}
```
now offers `&arg` as a completion option with the highest score.
bors[bot] [Thu, 22 Oct 2020 18:15:48 +0000 (18:15 +0000)]
Merge #6325 #6327
6325: Add generated diagnostic docs to the manual r=matklad a=flodiebold
It seemed that we're not actually including the generated diagnostic docs anywhere yet? So I added something to the manual. This is completely untested though.
Previously, line comments were able to break block comments by essentially commenting out the closing `*/`, resulting in a never-ending comment. This PR splits block comments into a separate repository group to fix this problem.
Since the comment scopes also include ignored parameters and inferred types, I've added the change proposed by @bnjjj in https://github.com/rust-analyzer/rust-analyzer/pull/6317, in order to close https://github.com/rust-analyzer/rust-analyzer/issues/6311 as well.
bors[bot] [Wed, 21 Oct 2020 20:09:11 +0000 (20:09 +0000)]
Merge #6307
6307: Add whitelist of safe intrinsics r=frazar a=frazar
This PR should fix #5996, where intrinsic operations where all marked as unsafe.
I'm rather new to this codebase, so I might be doing something *very* wrong. Please forgive me!
In particular, I'm not sure how to "check that we are in extern `rust-intrinsics`" as mentioned [in this comment](https://github.com/rust-analyzer/rust-analyzer/issues/5996#issuecomment-709234802).
Co-authored-by: Francesco Zardi <frazar@users.noreply.github.com>
bors[bot] [Wed, 21 Oct 2020 08:39:03 +0000 (08:39 +0000)]
Merge #6302
6302: Textmate grammar: fix raw string highlighting r=matklad a=dustypomerleau
1. Fixes the raw string highlighting issue noted by @matklad in https://github.com/rust-analyzer/rust-analyzer/pull/6275.
2. Improves raw string highlighting by requiring the number of surrounding `#` to match.
bors[bot] [Tue, 20 Oct 2020 17:03:19 +0000 (17:03 +0000)]
Merge #6172
6172: Add qualify path assist r=matklad a=Veykril
This implements a `qualify_path` assist which works quite similar to the `auto_import` assist but instead of adding imports to the file it well, qualifies the path. This PR also moves out the `AutoImportAssets` struct and functions from `auto_import` into a utils submodule as most of this is now shared between `auto_import` and `qualify_path`.
Changes made to `AutoImportAssets` are solely in its `search_for_imports` function which now takes a prefixed parameter to discern between using `find_use_path_prefixed` and `find_use_path` as the former is the required behavior by `auto_import` and the latter by this assist.
For missing imported traits instead of importing this will qualify the path with a trait cast as in:
```rust
test_mod::TestStruct::TEST_CONST<|>
```
becomes
```rust
<test_mod::TestStruct as test_mod::TestTrait>::TEST_CONST
```
and for trait methods ideally it would do the following:
```rust
let test_struct = test_mod::TestStruct {};
test_struct.test_meth<|>od()
```
becomes
```rust
let test_struct = test_mod::TestStruct {};
test_mod::TestTrait::test_method(&test_struct)
```
Aleksey Kladov [Tue, 20 Oct 2020 13:38:11 +0000 (15:38 +0200)]
Rename declaration_name -> display_name
Declaration names sounds like a name of declaration -- something you
can use for analysis. It empathically isn't, and is just a label
displayed in various UI. It's important not to confuse the two, least
we accidentally mix semantics with UI (I believe, there's already a
case of this in the FamousDefs at least).
Aleksey Kladov [Mon, 19 Oct 2020 13:18:28 +0000 (15:18 +0200)]
Try to fix publishing
This errro specifically:
Updating crates.io index
error: failed to select a version for the requirement `ra_ap_stdx = "^0.0.0"`
candidate versions found which didn't match: 0.0.20
location searched: /home/runner/work/rust-analyzer/rust-analyzer/crates/stdx
required by package `ra_ap_completion v0.0.20 (/home/runner/work/rust-analyzer/rust-analyzer/crates/completion)`
error: unable to update Cargo.lock
Error: Process completed with exit code 1.
bors[bot] [Sun, 18 Oct 2020 10:41:46 +0000 (10:41 +0000)]
Merge #6276
6276: Extract call_info and completion into separate crates r=matklad a=popzxc
As it was discussed in [zulip](https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Fwg-rls-2.2E0/topic/Completion.20refactoring), we need to move `completions` into a separate crate.
Unfortunately, the dependency on `call_info::ActiveParameter` doesn't look easy to get rid of, and it seems to be a topic for a separate PR, thus I also extracted `call_info` into a separate crate (on which both `ide` and `completion` crates depend).
Additionally, a few `FIXME`s in doc-comments were resolved in order to make `tidy` happy.
bors[bot] [Sat, 17 Oct 2020 10:31:37 +0000 (10:31 +0000)]
Merge #6262
6262: Do not spawn redundant hints r=SomeoneToIgnore a=popzxc
Closes #5206
This is a second part of the fix (first was #5997).
This PR adds a new method to the `CompletionContext`: `no_completion_required`. If this method returns `true`, it essentially means that user is unlikely to expect any hints from the IDE at this cursor position.
Currently, checks for the following cases were added:
- Previous item is `fn`: user creates a new function, names of existing functions won't be helpful. Exception for this case is `impl Foo for Bar` -- we must suggest trait function names.
- User entered `for _ i<|>`: it's obviously going to be `in` keyword, any hints here will be confusing.
More checks may be added there later, but currently I've only figured two cases.