Commit Graph

10234 Commits

Author SHA1 Message Date
bors[bot]
f0e78f2ed6
Merge #7961
7961: add user docs for ssr assist r=JoshMcguigan a=JoshMcguigan

@matklad 

This is a small follow up on #7874, adding user docs for the SSR assist functionality. Since most other assists aren't handled this way I wasn't sure exactly how we wanted to document this, so feel free to suggest alternatives.

Co-authored-by: Josh Mcguigan <joshmcg88@gmail.com>
2021-03-10 17:06:11 +00:00
Josh Mcguigan
40587b08a0 add user docs for ssr assist 2021-03-10 09:04:47 -08:00
Jonas Schievink
c2622c9228 Prefer names from outer DefMap over extern prelude 2021-03-10 16:33:18 +01:00
bors[bot]
83280ea574
Merge #7958
7958: Avoid double text edits when renaming mod declaration r=matklad a=Veykril

Closes https://github.com/rust-analyzer/rust-analyzer/issues/7916

See https://github.com/microsoft/vscode-languageserver-node/issues/752 for context

Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
2021-03-10 15:07:46 +00:00
Lukas Wirth
3af69b5359 Avoid double text edits when renaming mod declaration 2021-03-10 15:49:01 +01:00
Josh Mcguigan
09307be75b add apply ssr assist 2021-03-10 06:02:15 -08:00
Kirill Bulatov
94bb9cb9ee Fix labels for single import assists 2021-03-10 11:30:25 +02:00
Jonas Schievink
7beec8fda1 Stop fetching ItemTrees for no reason 2021-03-10 02:32:16 +01:00
bors[bot]
654313dbc7
Merge #6822
6822: Read version of rustc that compiled proc macro r=edwin0cheng a=jsomedon

Signed-off-by: Jay Somedon <jay.somedon@outlook.com>

This PR is to fix #6174.

I basically
* added two methods, `read_version` and `read_section`(used by `read_version`)
* two new crates `snap` and `object` to be used by those two methods

I just noticed that some part of code were auto-reformatted by rust-analyzer on file save. Does it matter?

Co-authored-by: Jay Somedon <jay.somedon@outlook.com>
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
2021-03-09 20:57:04 +00:00
Edwin Cheng
ad34e79bb9 use doc-comments 2021-03-10 04:54:31 +08:00
Aleksey Kladov
842d8ad9c8 Compilation speed 2021-03-09 22:30:58 +03:00
Jonas Schievink
b885e6bdee Delete ContainerId 2021-03-09 19:09:02 +01:00
bors[bot]
9a5c72d9f0
Merge #7878
7878: Remove `item_scope` field from `Body` r=jonas-schievink a=jonas-schievink

Closes https://github.com/rust-analyzer/rust-analyzer/issues/7632

Instead of storing an `ItemScope` filled with inner items, we store the list of `BlockId`s for all block expressions that are part of a `Body`. Code can then query the `block_def_map` for those.

bors r+

Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
2021-03-09 17:34:18 +00:00
Jonas Schievink
a430549aa6 Stop using ContainerId in AssocContainerId 2021-03-09 18:27:23 +01:00
Jonas Schievink
12f6bdcfd9 Check ancestor maps when computing traits in scope 2021-03-09 18:27:23 +01:00
Jonas Schievink
6be4f30cae Remove item_scope field from Body 2021-03-09 18:27:23 +01:00
Jonas Schievink
1da0a27626 Use body.block_scopes in hir_ty tests 2021-03-09 18:27:23 +01:00
Jonas Schievink
0cb46a9e8d Use body.block_scopes to validate inner items 2021-03-09 18:27:23 +01:00
Jonas Schievink
c12f7be8d3 Use body.block_scopes in ChildBySource 2021-03-09 18:27:23 +01:00
Jonas Schievink
13f4356d2f Store inner BlockIds in Body 2021-03-09 18:27:23 +01:00
Jonas Schievink
8da50c9077 Change ChildBySource to allow reusing DynMap 2021-03-09 18:27:23 +01:00
bors[bot]
84eed2136b
Merge #7945
7945: Future proof completion scores r=matklad a=matklad

bors r+
🤖

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
2021-03-09 17:25:23 +00:00
Aleksey Kladov
b2764a6641 Future proof completion scores 2021-03-09 20:24:09 +03:00
bors[bot]
c45ac6effe
Merge #7942
7942: Show whether a binding is mutable or not on hover r=Veykril a=Veykril

bors r+

Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
2021-03-09 16:23:51 +00:00
Lukas Wirth
814d617d34 Show whether a binding is mutable or not on hover 2021-03-09 17:18:50 +01:00
bors[bot]
c2359608c9
Merge #7944
7944: Selecting `&mut foo` completion now actually inserts `&mut` r=matklad a=matklad

bors r+
🤖

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
2021-03-09 16:05:23 +00:00
Aleksey Kladov
73b9937e4e Selecting &mut foo completion now actually inserts &mut 2021-03-09 19:04:27 +03:00
Lukas Wirth
983726a45c Don't show const items initializer expressions on hover 2021-03-09 16:33:23 +01:00
Aleksey Kladov
12fe301a0c Cleanup auto-ref in completion 2021-03-09 18:06:08 +03:00
bors[bot]
472641fc5b
Merge #7941
7941: Fix unused definitions not being document highlit r=Veykril a=Veykril

Fixes #7939

bors r+

Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
2021-03-09 14:54:24 +00:00
Lukas Wirth
a1f080138a Fix unused definitions not being document highlit 2021-03-09 15:45:31 +01:00
Aleksey Kladov
abc0ed36bd Cleanup 2021-03-09 17:44:27 +03:00
Aleksey Kladov
444d67ae18 Cleanup 2021-03-09 17:42:05 +03:00
Aleksey Kladov
2cc278c6ff Fix bad names
`res` should only be used for the result variable
2021-03-09 17:39:22 +03:00
bors[bot]
21913d0fdb
Merge #7873 #7933
7873: Consider unresolved qualifiers during flyimport r=matklad a=SomeoneToIgnore

Closes https://github.com/rust-analyzer/rust-analyzer/issues/7679

Takes unresolved qualifiers into account, providing better completions (or none, if the path is resolved or do not match).

Does not handle cases when both path qualifier and some trait has to be imported: there are many extra issues with those (such as overlapping imports, for instance) that will require large diffs to address.

Also does not do a fuzzy search on qualifier, that requires some adjustments in `import_map` for better queries and changes to the default replace range which also seems relatively big to include here.

![qualifier_completion](https://user-images.githubusercontent.com/2690773/110040808-0af8dc00-7d4c-11eb-83db-65af94e843bb.gif)


7933: Improve compilation speed r=matklad a=matklad

bors r+
🤖

Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
2021-03-09 11:58:48 +00:00
Aleksey Kladov
867fdf8f03 Improve compilation speed 2021-03-09 14:54:50 +03:00
Aleksey Kladov
37b7b56821 Make code less surprising
Theres no reason to have literal `\n\n` in the source code
2021-03-09 14:47:42 +03:00
bors[bot]
ffba4c0dce
Merge #7931
7931: Use `Type::new_with_resolver_inner` more r=jonas-schievink a=jonas-schievink

bors r+

Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
2021-03-09 11:36:40 +00:00
Jonas Schievink
30791c5295 Use Type::new_with_resolver_inner more 2021-03-09 12:31:16 +01:00
bors[bot]
844b7f7411
Merge #7927
7927: Add more documentation for rustc_private r=matklad a=jyn514



Co-authored-by: Joshua Nelson <jyn514@gmail.com>
2021-03-09 11:22:37 +00:00
Duong Do Minh Chau
73590f0f0b
Fix format 2021-03-09 16:38:07 +07:00
Duong Do Minh Chau
a068cedee0
Add trailing commas 2021-03-09 16:00:06 +07:00
Duong Do Minh Chau
ea835fc800
Update the test to match the change 2021-03-09 15:48:53 +07:00
Duong Do Minh Chau
5fc91058ff
Add completion to turn x.err into Err(x) 2021-03-09 15:36:41 +07:00
bors[bot]
3fdf26a6fc
Merge #7898
7898: generate_function assist: infer return type r=JoshMcguigan a=JoshMcguigan

This PR makes two changes to the generate function assist:

1. Attempt to infer an appropriate return type for the generated function
2. If a return type is inferred, and that return type is not unit, don't render the snippet

```rust
fn main() {
    let x: u32 = foo$0();
    //              ^^^ trigger the assist to generate this function
}

// BEFORE
fn foo() ${0:-> ()} {
    todo!()
}

// AFTER (only change 1)
fn foo() ${0:-> u32} {
    todo!()
}

// AFTER (change  1 and 2, note the lack of snippet around the return type)
fn foo() -> u32 {
    todo!()
}
```

These changes are made as two commits, in case we want to omit change 2. I personally feel like it is a nice change, but I could understand there being some opposition.

#### Pros of change 2
If we are able to infer a return type, and especially if that return type is not the unit type, the return type is almost as likely to be correct as the argument names/types. I think this becomes even more true as people learn how this feature works.

#### Cons of change 2

We could never be as confident about the return type as we are about the function argument types, so it is more likely a user will want to change that. Plus it is a confusing UX to sometimes have the cursor highlight the return type after triggering this assist and sometimes not have that happen.

#### Why omit unit type?

The assumption is that if we infer the return type as unit, it is likely just because of the current structure of the code rather than that actually being the desired return type. However, this is obviously just a heuristic and will sometimes be wrong. But being wrong here just means falling back to the exact behavior that existed before this PR.



Co-authored-by: Josh Mcguigan <joshmcg88@gmail.com>
2021-03-08 22:51:04 +00:00
Josh Mcguigan
b275e60905 generate_function assist don't render snippet if ret type inferred 2021-03-08 14:38:36 -08:00
Kirill Bulatov
778deb38fe Better strip turbofishes 2021-03-08 23:59:39 +02:00
Kirill Bulatov
5168ab16e1 Add rustdocs and use better names 2021-03-08 23:59:37 +02:00
Kirill Bulatov
dccbb38d2e Less lifetines: derive SemanticsScope in place 2021-03-08 23:59:20 +02:00
Kirill Bulatov
db61d4ea13 Rebase leftovers 2021-03-08 23:59:20 +02:00