1652: Improve type hints behavior r=matklad a=SomeoneToIgnore
This PR fixed the following type hints issues:
* Restructures the `InlayKind` enum contents based on the discussion here: https://github.com/rust-analyzer/rust-analyzer/pull/1606#issuecomment-515968055
* Races described in #1639
* Caches the latest decorations received for each file to show them the next time the file is opened (instead of a new server request)
Co-authored-by: Kirill Bulatov <mail4score@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>
This appears to have been introduced ages ago in
be742a5877
but has since been removed.
As it stands, it is problematic if multiple instances of the
rust-analyzer LSP are launched during the same VS Code session because
VS Code complains about multiple LSP servers trying to register the
same command.
Most LSP servers workaround this by parameterizing the command by the
process id. For example, this is where `rls` does this:
ff0b9057c8/rls/src/server/mod.rs (L413-L421)
Though `apply_code_action` does not seems to be used, so it seems better
to delete it than to parameterize it.
This wasn't a right decision in the first place, the feature flag was
broken in the last rustfmt release, and syntax highlighting of imports
is more important anyway