1586: Add type decorators r=matklad a=SomeoneToIgnore
A follow-up of https://github.com/rust-analyzer/rust-analyzer/pull/1549
Now the frontend shows inlay hints as VS Code Decorators:
<img width="666" alt="image" src="https://user-images.githubusercontent.com/2690773/61802687-918fcc80-ae39-11e9-97b0-3195ab467393.png">
<img width="893" alt="image" src="https://user-images.githubusercontent.com/2690773/61802688-93599000-ae39-11e9-8bcb-4512e22aa3ed.png">
A few notes on the implementation:
* I could not find a normal way to run and display the hints for the file that's already open in the VS Code when it starts.
The updating code runs ok, but does not actually show anything.
Seems like I miss some event that I could add a handler to.
I've also experimented with `setTimeout` and it worked, but this is too ugly.
The hints appear now when a new file is open or when some change is done in the existing file.
* If there's a `dbg!` used in the lsp_server, the frontend starts receiving change events that contain the string from the `dbg!` output.
It should not be the case in a real life, but I've decided to cover this case, just in case.
* For bigger files, ~500 lines, the decorators start to blink, when updated, this does not seem to be very much of a problem for me at this particular stage of the feature development and can be optimized later. In the worst case, those decorators can be turned off in settings.
* Cursor movement is rather non-intuitive on the right edge of the decorator.
Seems like a thing to fix in the VS Code, not in the plugin.
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
1590: Update crossbeam to pull in new memoffset r=matklad a=kjeremy
Fixes `cargo audit` complaints about memoffset being unsound.
Co-authored-by: kjeremy <kjeremy@gmail.com>
1549: Show type lenses for the resolved let bindings r=matklad a=SomeoneToIgnore
Types that are fully unresolved are not displayed:
<img width="279" alt="image" src="https://user-images.githubusercontent.com/2690773/61518122-8e4ba980-aa11-11e9-9249-6d9f9b202e6a.png">
A few concerns that I have about the current implementation:
* I've adjusted the `file_structure` API method to return the information about the `let` bindings.
Although it works fine, I have a feeling that adding a new API method would be the better way.
But this requires some prior discussion, so I've decided to go for an easy way with an MVP.
Would be nice to hear your suggestions.
* There's a hardcoded `{undersolved}` check that I was forced to use, since the method that resolves types returns a `String`.
Is there a better typed API I can use? This will help, for instance, to add an action to the type lenses that will allow us to navigate to the type.
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
