Commit Graph

7140 Commits

Author SHA1 Message Date
bors[bot]
c78d269b66
Merge #2837
2837: Accidentally quadratic r=matklad a=matklad

Our syntax highlighting is accdentally quadratic. Current state of the PR fixes it in a pretty crude way, looks like for the proper fix we need to redo how source-analyzer works. 

**NB:** don't be scared by diff stats, that's mostly a test-data file

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
2020-01-15 19:38:10 +00:00
bors[bot]
aa2e13b37f
Merge #2716
2716: Allow assists with multiple selectable actions r=SomeoneToIgnore a=SomeoneToIgnore

This PR prepares an infra for https://github.com/rust-analyzer/rust-analyzer/issues/2180 task by adding a possibility to specify multiple actions in one assist as multiple edit parameters to the `applySourceChange` command.

When this is done, the command opens a selection dialog, allowing the user to pick the edit to be applied.

I have no working example to test in this PR, but here's a demo of an auto import feature (a separate PR coming later for that one) using this functionality:

![out](https://user-images.githubusercontent.com/2690773/71633614-f8ea4d80-2c1d-11ea-9b15-0e13611a7aa4.gif)

The PR is not that massive as it may seem: all the assist files' changes are very generic and similar.

Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
2020-01-15 18:43:23 +00:00
Kirill Bulatov
79b77403b6 Reduce visibility 2020-01-15 20:21:05 +02:00
Kirill Bulatov
d51cf7794d itertools::Either -> either::Either 2020-01-15 20:20:20 +02:00
Kirill Bulatov
78a21253b4 Apply the api design suggestions 2020-01-15 20:17:17 +02:00
Kirill Bulatov
73dc8b6f06 Another attempt to add multiple edits 2020-01-15 20:16:27 +02:00
bors[bot]
01422cc31d
Merge #2856
2856: More orthogonal path editing r=matklad a=matklad



Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
2020-01-15 17:54:41 +00:00
Aleksey Kladov
ef1326ee19 More orthogonal path editing 2020-01-15 18:48:28 +01:00
bors[bot]
2f1df3cd74
Merge #2855
2855: More fluent API r=matklad a=matklad



Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
2020-01-15 17:32:34 +00:00
Aleksey Kladov
7d2d3ac3db More fluent API 2020-01-15 18:30:23 +01:00
Aleksey Kladov
c84010e246 Slightly more fluent API 2020-01-15 18:14:49 +01:00
Aleksey Kladov
8296d3208d Simplify 2020-01-15 18:01:05 +01:00
Aleksey Kladov
448575aa4a Simplify 2020-01-15 18:01:05 +01:00
Aleksey Kladov
263401bf75 Rename 2020-01-15 17:44:12 +01:00
Aleksey Kladov
aaef88db0e Typos 2020-01-15 16:53:01 +01:00
Aleksey Kladov
5b255b4e6b ⬆️ once_cell 2020-01-15 16:52:28 +01:00
Aleksey Kladov
787d1aba63 Add comment 2020-01-15 16:52:28 +01:00
Aleksey Kladov
4194e5c88c Optimize inlay hints 2020-01-15 16:52:28 +01:00
Aleksey Kladov
11d6b9dadd Only new-style classification 2020-01-15 16:52:28 +01:00
Aleksey Kladov
35bfeaf4af Add a test 2020-01-15 16:52:28 +01:00
Aleksey Kladov
c640c2ea11 Make syntax highlighting linear 2020-01-15 16:52:28 +01:00
Aleksey Kladov
7e70fc22a7 Flip generics 2020-01-15 16:52:28 +01:00
Aleksey Kladov
a71bb70f0a Store DB in SourceBinder 2020-01-15 16:52:28 +01:00
Aleksey Kladov
ccfe53376a Introduce SourceBinder 2020-01-15 16:52:28 +01:00
bors[bot]
c0661ce744
Merge #2853
2853: Manage `cargo check` state updates in `main_loop` to reduce lock contention r=matklad a=kiljacken

State is now updated exclusively from `main_loop` so several threads theoretically can't compete for the lock. Updates to the state are requested via the existing task channel.

Also updates some naming to make slightly more sense.

Based upon an idea/suggestion from @matklad on Zulip:

> I think I've noticed at leas something suspicious!
> 
> In WorldSnapshot, we store an Arc<RwLock<CheckWatcherSharedState>>. We read lock this lock in handle_diagnostics.
> 
> Additionally, we .write this lock from the watcher thread in CheckWatcherState::run.
> 
> I think in general this is less then ideal, b/c diagnostics request can be blocked on another thread. I think it makes sense to architect this in a way which does not block.
>
> For that, we stop sharing the state between ServerWorld and CheckWatcherState. Instead, the watcher thread sends new diagnostics via a channel, and we accomodate thouse diagnostics intot he server state in the main loop.
> 
> So, instead of:
> ```rust
> struct Server {
>     diagnostics: Arc<Mutex<Vec<Diagnostics>>>,
> }
> 
> struct Watcher {
>     diagnostics: Arc<Mutex<Vec<Diagnostics>>>,
> }
> ```
> we'll have something like this:
> ```rust
> struct Server {
>     // this bit now *owns* diagnostics
>     diagnostisc: Vec<Diagnostics>
> }
> 
> struct Watcher {
>     diagnostics_sink: Sender<Vec<Diagnostics>>,
> }
> ```
> I am not sure this is the cuprit of slowness on widnows, but I think we should fix it, because it's very useful when all changes to the server's state can occur only via the main loop.
> 
> Note how VFS is set up in a similar way: instead of modifing some global hash map with files, VFS sends a message to the main looop that hey, I have these new files for you. The main loop than incorporates the changes itself.
> 
> Note that I think we'll still need some locks here, to share the state between ServerWorld and WorldSnapshot, but we won't actually be changing anyting mid-snapshot


Co-authored-by: Emil Lauridsen <mine809@gmail.com>
2020-01-15 15:37:28 +00:00
Emil Lauridsen
7a8c6351bf Extract check task handling into function 2020-01-15 16:33:58 +01:00
bors[bot]
8013636768
Merge #2854
2854: Add logo r=matklad a=matklad



Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
2020-01-15 15:09:19 +00:00
Aleksey Kladov
f10b209234 Extension icon 2020-01-15 16:07:39 +01:00
Emil Lauridsen
ade657cb66 Tweak naming slightly 2020-01-15 15:53:08 +01:00
Emil Lauridsen
478ba65f8d Manage check state updates in main_loop to reduce lock contention 2020-01-15 15:50:49 +01:00
Aleksey Kladov
286930f1b6 Add logo 2020-01-15 15:48:11 +01:00
bors[bot]
fdb13dade9
Merge #2852
2852: Don't parse child modules when doing diagnostics r=matklad a=matklad



Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
2020-01-15 13:45:40 +00:00
Aleksey Kladov
21ea62d292 Don't parse child modules when doing diagnostics 2020-01-15 14:42:57 +01:00
bors[bot]
4a9e4ec7e1
Merge #2851
2851: lsp-types 0.69.0 r=kjeremy a=kjeremy

Stabilizes most proposed features

Co-authored-by: Jeremy Kolb <kjeremy@gmail.com>
2020-01-15 13:07:14 +00:00
Jeremy Kolb
e1688be1bb lsp-types 0.69.0
Stabilizes most proposed features
2020-01-15 08:05:42 -05:00
bors[bot]
5449d267b8
Merge #2850
2850: Use types from vscode-languageclient r=matklad a=kiljacken

Now that we're running with 3.15 of the LSP for VSCode we don't need to define these interfaces ourselves. Yay!

Co-authored-by: Emil Lauridsen <mine809@gmail.com>
2020-01-15 11:08:12 +00:00
Emil Lauridsen
70cba0fe0f Use types from vscode-langaugeclient 2020-01-15 12:04:35 +01:00
bors[bot]
876f92d547
Merge #2843
2843: Add inlay parameter name hints for call expr r=matklad a=imtsuki

This patch adds Intellij-like parameter name hints for literal values in function calls.

<img width="624" alt="Screenshot" src="https://user-images.githubusercontent.com/8423594/72366533-68d7f800-3735-11ea-9279-cf193ca8ca2f.png">

Signed-off-by: imtsuki <me@qjx.app>

Co-authored-by: imtsuki <me@qjx.app>
2020-01-15 10:24:51 +00:00
bors[bot]
bc8be6bcdb
Merge #2849
2849: Display vscode message after changing cargo-watch options r=edwin0cheng a=memoryruins

Currently, changed cargo-watch settings do not go into effect until after a reload.
This PR checks for changed `cargoWatchOptions` in the same way as the current `cargoFeatures` check.

![2020-01-14_20-52-20](https://user-images.githubusercontent.com/6868531/72398362-b5f5a300-3710-11ea-9bc1-9943bef08447.gif)


Co-authored-by: memoryruins <memoryruinsmusic@gmail.com>
2020-01-15 04:00:52 +00:00
memoryruins
896a162f55 Improve readability 2020-01-14 22:52:49 -05:00
memoryruins
edb820c329 Display vscode message after changing cargo-watch options 2020-01-14 20:52:48 -05:00
imtsuki
d854ad8f27 FnSignature: use unwrap_or_default for parameter_name_list
Signed-off-by: imtsuki <me@qjx.app>
2020-01-15 09:30:19 +08:00
bors[bot]
754d9d1a0c
Merge #2846
2846: Language Server Protocol 3.15 is now stable r=kjeremy a=kjeremy

Update the client

Co-authored-by: kjeremy <kjeremy@gmail.com>
2020-01-14 20:36:42 +00:00
kjeremy
385c548032 Language Server Protocol 3.15 is now stable
Update the client
2020-01-14 14:53:38 -05:00
bors[bot]
eceafa65d5
Merge #2845
2845: Cleanup assert r=kjeremy a=kjeremy

Re: https://github.com/rust-analyzer/rust-analyzer/pull/2841#discussion_r366510725

thanks @bjorn3!

Co-authored-by: kjeremy <kjeremy@gmail.com>
2020-01-14 18:56:57 +00:00
kjeremy
e89ade3809 Cleanup assert 2020-01-14 13:55:32 -05:00
bors[bot]
b2ed130ffd
Merge #2841
2841: More UI friendly labels r=kjeremy a=kjeremy



Co-authored-by: Jeremy Kolb <kjeremy@gmail.com>
2020-01-14 18:16:11 +00:00
Jeremy Kolb
864434137a unwrap 2020-01-14 13:15:41 -05:00
bors[bot]
767ff2c13c
Merge #2844
2844: Use dummy value for line! and column! macro r=matklad a=edwin0cheng

Use dummy value `0` for line! and column! macro. 

Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
2020-01-14 17:59:24 +00:00
bors[bot]
6a5100f4d5
Merge #2834
2834: refactor(ra_syntax.validation): removed code duplication from validate_literal() r=kiljacken a=Veetaha

Hi! This is my first ever contribution to this project.
I've taken some dirty job from issue #223

This is a simple atomic PR to remove code duplication according to FIXME comment in the function that is the main focus of the further development.

I just didn't want to mix refactoring with the implementation of new features...

I am not sure whether you prefer such atomic PRs here or you'd rather have a single PR that contains all atomic commits inside of it?

So if you want me to add all that validation in one PR I'll mark this one as WIP and update it when the work is finished, otherwise, I'll go with the option of creating separate PRs per each feature of validation of strings, numbers, and comments respectively.

### Comments about refactoring
Yeah, reducing the duplication is quite hard here, extracting into stateless functions could be another option but the number of their arguments would be very big and repeated across char and string implementations so that just writing their types and names would become cumbersome.
I tried the option of having everything captured implicitly in the closure but failed since rust doesn't have templated (or generic) closures as C++ does, this is needed because `unescape_byte*()` and `unescape_char|str()` have different return types...
Maybe I am missing something here? I may be wrong because I am not enough experienced in Rust...
Well, I am awaiting any kind of feedback!

Co-authored-by: Veetaha <gerzoh1@gmail.com>
2020-01-14 17:49:18 +00:00