3099: Init implementation of structural search replace r=matklad a=mikhail-m1
next steps:
* ignore space and other minor difference
* add support to ra_cli
* call rust parser to check pattern
* documentation
original issue #2267
Co-authored-by: Mikhail Modin <mikhailm1@gmail.com>
3162: Feature: vscode always downloads only the matching ra_lsp_server version r=matklad a=Veetaha
I tried to separate logically connected changes into separate commits, so enjoy!
Now TypeScript extension saves installed binary version in global state and always checks that the installed binary version equals the version of the TypeScript extension itself (to prevent version drifts).
Also, changed `fetchLatestArtifactReleaseInfo()` to `fetchArtifactReleaseInfo()` that takes an optional release tag (when not specified fetches the latest release). The version without a release tag will be useful in the future when adding auto-checking for updates.
I decided not to do `Download latest language server` command (I have stated the rationale for this in #3073) and let the extension itself decide which version of the binary it wants. This way the users will be able to get the latest `ra_lsp_server` binary after the approaching 2020-02-17 release, without having to manually delete the outdated one from `~/.config/Code/User/globalStorage/matklad.rust-analyzer`!
Closes#3073
Co-authored-by: Veetaha <gerzoh1@gmail.com>
3131: vscode: simplified config and to removed one source of truth of default values r=matklad a=Veetaha
Though not intended initially, the implementation of config design is alike [dart's one](https://github.com/Dart-Code/Dart-Code/blob/master/src/extension/config.ts) as pointed by @matklad in PM.
Co-authored-by: Veetaha <gerzoh1@gmail.com>
3137: Do not register all proposed features r=matklad a=kjeremy
Instead only opt-in to CallHierarchy since it has a vscode API but LSP support
is still proposed.
Discovered while working on SemanticTokens which does not have a vscode API
and is still in the proposed state. Somehow enabling it would crash the
language server.
See https://github.com/microsoft/vscode-languageserver-node/issues/572
Co-authored-by: kjeremy <kjeremy@gmail.com>
Instead only opt-in to CallHierarchy since it has a vscode API but LSP support
is still proposed.
Discovered while working on SemanticTokens which does not have a vscode API
and is still in the proposed state. Somehow enabling it would crash the
language server.
See https://github.com/microsoft/vscode-languageserver-node/issues/572
