3543: Parameter inlay hint separate from variable type inlay? #2876 r=matklad a=slyngbaek
Add setting to allow enabling either type inlay hints or parameter
inlay hints or both. Group the the max inlay hint length option
into the object.
- Add a new type for the inlayHint options.
- Add tests to ensure the inlays don't happen on the server side
Co-authored-by: Steffen Lyngbaek <steffenlyngbaek@gmail.com>
- Instead of a single object type, use several individual nested types
to allow toggling from the settings GUI
- Remove unused struct definitions
- Install and test that the toggles work
3549: Implement env! macro r=matklad a=edwin0cheng
This PR implements `env!` macro by adding following things:
1. Added `additional_outdirs` settings in vscode. (naming to be bikeshed)
2. Added `ExternSourceId` which is a wrapping for SourceRootId but only used in extern sources. It is because `OUT_DIR` is not belonged to any crate and we have to access it behind an `AstDatabase`.
3. This PR does not implement the `OUT_DIR` parsing from `cargo check`. I don't have general design about this, @kiljacken could we reuse some cargo watch code for that ?
~~Block on [#3536]~~
PS: After this PR , we (kind of) completed the `include!(concat!(env!('OUT_DIR'), "foo.rs")` macro call combo. [Exodia Obliterate!](https://www.youtube.com/watch?v=RfqNH3FoGi0)
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
- Updated naming of config
- Define struct in ra_ide and use remote derive in rust-analyzer/config
- Make inlayConfig type more flexible to support more future types
- Remove constructor only used in tests
Add setting to allow enabling either type inlay hints or parameter
inlay hints or both. Group the the max inlay hint length option
into the object.
- Add a new type for the inlayHint options.
- Add tests to ensure the inlays don't happen on the server side
3514: vscode: askBeforeDownload option r=matklad a=Veetaha
This is a small step towards #3402, also implements my proposal stated in #3403
Also renamed `BinarySource` to `ArtifactSource` in anticipation of nightlies installation that requires downloading not a binary itself but `.vsix` package, thus generalized to `artifact` term.
@matklad @lnicola
Co-authored-by: Veetaha <gerzoh1@gmail.com>
The new name seems much simpler and it doesn't limit
this config value only to downloading the server binary.
Thus we wouldn't need to create another config
properties to handle other downloads whatsoever.
Anyway, I believe (heuristically) that most of the users
would want to set "askBeforeDownload": false once
and never bother clicking on the notification again
(because otherwise there is no big point in installing rust-analyzer if it cannot install the server)
Also renamed BinarySource to ArtifactSource in anticipation of
nightlies installation that requires downloading
not a binary itself but .vsix package, thus generalized
to `artifact` term
3388: Remove inlay hint in diff views r=matklad a=vbfox
If the left side of a diff view that contain the old version of the file apply inlays they are misplaced and produce a weird display:
After the change:
The detection is done by blacklisting the url schemes used by git and subversion scm extensions, whitelisting `file` is also possible but neither is perfect as VSCode now support both pluggable scm extensions and pluggable remote filesystems. But I suspect that the list of scm extensions is more easily manageable.
**Note**: I can rebase on #3378 if needed as it touches the same lines of code
Co-authored-by: Julien Roncaglia <julien@roncaglia.fr>
If the left side of a diff view that contain the old
version of the file apply inlays they are misplaced.
The detection is done by blacklisting the url schemes used
by git and subversion scm extensions.
3361: Reset fontStyle for inlay hints r=matklad a=matklad
Otherwise, we get bold hints on `true` and `false`
bors r+
🤖
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
3308: vscode: fix vscode-vim keybindings conflict r=matklad a=Veetaha
Closes#3013 I hope
vscode-vim extension overrides the `type` command so that it prevents
some keypresses to reach the text document editor.
It conflicts with our `onEnter` keybinding
that is used to support automatic doc comments extending and
indentation insertion.
The VSCode-native way to implement this would be
to use regular expressions, but as per matklad it is
considered not acceptable for the language server.
Thus we implement it via a `Enter` keybinding that
invokes our `onEnter` command which does it via the language-server.
At the end of the day we may only apply
ad hoc workarounds for conflicting extensions.
But vscode has another bug for that. You
either cannot use parantheses in `when` condition
of a keybinding or it just malfunctions.
See an issue about that here: https://github.com/microsoft/vscode/issues/91473
To get the ultimate context, follow this [zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Fwg-rls-2.2E0/topic/Enhanced.20typing)
Co-authored-by: Veetaha <gerzoh1@gmail.com>
vscode-vim extension overrides the `type` command so that it prevents
some keypresses to reach the text document editor.
It conflicts with our `onEnter` keybinding
that is used to support automatic doc comments extending and
indentation insertion.
The VSCode-native way to implement this would be
to use regular expressions, but as per matklad it is
considered not acceptable for the language server.
Thus we implement it via a `Enter` keybinding that
invokes our `onEnter` command which sends
a request to rust-analyzer process and applies
the appropriate source change recieved from it.
At the end of the day we may only apply
ad hoc workarounds for conflicting extensions.
But vscode has another bug for that. You
either cannot use parantheses in `when` condition
of a keybinding or it just malfunctions.
See an issue about that here: https://github.com/microsoft/vscode/issues/91473
To get the ultimate context, follow this zulip thread: https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Fwg-rls-2.2E0/topic/Enhanced.20typing
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
3083: Update some crates r=matklad a=kjeremy
3101: vscode: filter out arm linux from using prebuilt binaries r=matklad a=Veetaha
Closes#3076
Co-authored-by: kjeremy <kjeremy@gmail.com>
Co-authored-by: Veetaha <gerzoh1@gmail.com>
2979: vscode: now we are actually using tslib r=matklad a=Veetaha
We had an incorrect setup where `tslib` was in `devDependencies`.
FYI:
tslib is a runtime dependency, it contains functions that are used by transpiled JavaScript in order not to inline them in each file.
For example:
```ts
// foo.ts (source code)
import * as foo from "foo";
// ---------------------------
// foo.js (compiled output)
"use strict";
var __importStar = (this && this.__importStar) || function (mod) {
if (mod && mod.__esModule) return mod;
var result = {};
if (mod != null) for (var k in mod) if (Object.hasOwnProperty.call(mod, k)) result[k] = mod[k];
result["default"] = mod;
return result;
};
Object.defineProperty(exports, "__esModule", { value: true });
const foo = __importStar(require("foo"));
```
As you see, `tsc` generated that `__importStar` helper function in compiled output. And it generates it per each file if you don't enable `"importHelpers": true`. Now with `importHelpers` enabled we get the following picture:
```ts
// foo.ts (source code)
import * as foo from "foo";
// ---------------------------
// foo.js (compiled output)
"use strict";
Object.defineProperty(exports, "__esModule", { value: true });
const tslib_1 = require("tslib");
const foo = tslib_1.__importStar(require("foo"));
```
It saves some bundle size, but I am not entirely sure wheter we want that. Discussions are welcome!
Co-authored-by: Veetaha <gerzoh1@gmail.com>
2964: Improve responsiveness of the cargo check status label r=matklad a=lnicola
This is still not ideal because the label displays the crate that was just checked, not the one that's currently being checked. But it should give the impression of being faster.
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
