9258: minor: Give `ImportPrefix` variants better config names r=matklad a=Veykril
I feel like `crate` and `self` work better than `by_crate` and `by_self`. The only reason for the current names were that `Self` doesn't work for the variant name on the rust side so I forgot about setting proper config names on serde layer.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9267: fix: Code: update the LSP server without asking r=matklad a=lnicola
Most LSP extensions seem to do the same thing, and this is causing some
confusion for users who don't notice the update prompt before Code hides
it.
9279: minor: Document installation via Homebrew r=matklad a=Svetlitski
`rust-analyzer` can be installed via [Homebrew](https://brew.sh) (AKA`brew`) on macOS. I've added instructions on how to do so to the documentation. Additionally, I added a `.gitignore` rule to ignore the HTML documentation produced by `asciidoctor manual.adoc` so that it is not accidentally checked into `git`.
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
Co-authored-by: Kevin Svetlitski <kevin_svetlitski@berkeley.edu>
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
8873: Implement import-granularity guessing r=matklad a=Veykril
This renames our `MergeBehavior` to `ImportGranularity` as rustfmt has it as the purpose of them are basically the same. `ImportGranularity::Preserve` currently has no specific purpose for us as we don't have an organize imports assist yet, so it currently acts the same as `ImportGranularity::Item`.
We now try to guess the import style on a per file basis and fall back to the user granularity setting if the file has no specific style yet or where it is ambiguous. This can be turned off by setting `import.enforceGranularity` to `true`.
Closes https://github.com/rust-analyzer/rust-analyzer/issues/8870
Co-authored-by: Lukas Tobias Wirth <lukastw97@gmail.com>
The new extension allows filtering of workspace symbool lookup
results by search scope or search kind.
Filtering can be configured in 3 different ways:
- The '#' or '*' markers can be added inline with the symbol lookup
query.
The '#' marker means symbols should be looked up in the current
workspace and any dependencies. If not specified, only current
workspace is considered.
The '*' marker means all kinds of symbols should be looked up
(types, functions, etc). If not specified, only type symbols are
returned.
- Each LSP request can take an optional search_scope or search_kind
argument query parameter.
- Finally there are 2 global config options that can be set for all
requests served by the active RA instance.
Add support for setting the global config options to the VSCode
extension.
The extension does not use the per-request way, but it's useful for
other IDEs.
The latest version of VSCode filters out the inline markers, so
currently the only reasonable way to use the new functionality is
via the global config.
8795: Allow semantic tokens for strings to be disabled r=matklad a=djrenren
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/7111
Pretty straightforward change, but open to any suggestions if there's a more recommended testing strategy than what I went with.
Co-authored-by: John Renner <john@jrenner.net>
8624: Automatically detect rust library source file map r=vsrs a=vsrs
This PR adds a new possible `rust-analyzer.debug.sourceFileMap` value:
```json
{
"rust-analyzer.debug.sourceFileMap": "auto"
}
```
I did not make it the default because it uses two shell calls (`rustc --print sysroot` and `rustc -V -v`). First one can be slow (https://github.com/rust-lang/rustup/issues/783)
Fixes#8619
Co-authored-by: vsrs <vit@conrlab.com>
7891: Improve handling of rustc_private r=matklad a=DJMcNab
This PR changes how `rust-analyzer` handles `rustc_private`. In particular, packages now must opt-in to using `rustc_private` in `Cargo.toml`, by adding:
```toml
[package.metadata.rust-analyzer]
rustc_private=true
```
This means that depending on crates which also use `rustc_private` will be significantly improved, since their dependencies on the `rustc_private` crates will be resolved properly.
A similar approach could be used in #6714 to allow annotating that your package uses the `test` crate, although I have not yet handled that in this PR.
Additionally, we now only index the crates which are transitive dependencies of `rustc_driver` in the `rustcSource` directory. This should not cause any change in behaviour when using `rustcSource: "discover"`, as the source used then will only be a partial clone. However, if `rustcSource` pointing at a local checkout of rustc, this should significantly improve the memory usage and lower indexing time. This is because we avoids indexing all crates in `src/tools/`, which includes `rust-analyzer` itself.
Furthermore, we also prefer named dependencies over dependencies from `rustcSource`. This ensures that feature resolution for crates which are depended on by both `rustc` and your crate uses the correct set for analysing your crate.
See also [introductory zulip stream](https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Fwg-rls-2.2E0/topic/Fixed.20crate.20graphs.20and.20optional.20builtin.20crates/near/229086673)
I have tested this in [priroda](https://github.com/oli-obk/priroda/), and it provides a significant improvement to the development experience (once I give `miri` the required data in `Cargo.toml`)
Todo:
- [ ] Documentation
This is ready to review, and I will add documentation if this would be accepted (or if I get time to do so anyway)
Co-authored-by: Daniel McNab <36049421+DJMcNab@users.noreply.github.com>
7901: Make extension respect http proxy settings r=matklad a=kamyuentse
This patch makes vscode extension respect proxy settings when fetching release metadata and rust-analyzer binary.
Co-authored-by: Kam Y. Tse <kevin.xjy@gmail.com>
Rather than eagerly converting JSON, we losslessly keep it as is, and
change the shape of user-submitted data at the last moment.
This also allows us to remove a bunch of wrong Defaults
7068: Add VSCode command to view the hir of a function body r=theotherphil a=theotherphil
Will fix https://github.com/rust-analyzer/rust-analyzer/issues/7061. Very rough initial version just to work out where I needed to wire everything up.
@matklad would you be happy merging a hir visualiser of some kind? If so, do you have any thoughts on what you'd like it show, and how?
I've spent very little time on this thus far, so I'm fine with throwing away the contents of this PR, but I want to avoid taking the time to make this more polished/interactive/useful only to discover that no-one else has any interest in this functionality.
Co-authored-by: Phil Ellison <phil.j.ellison@gmail.com>
6993: Clean up descriptions for settings r=matklad a=rherrmann
Use two consecutive newlines (`\n\n`) to actually continue text on a
new line.
Use proper markup to reference related settings.
Consistently format references to files, command line arguments, etc.
as `code`. Format mentions of UI elements in _italic_.
Fix typos, add missing full-stops, add missing default values.
Co-authored-by: Rüdiger Herrmann <ruediger.herrmann@gmx.de>
Use two consecutive newlines (`\n\n`) to actually continue text on a
new line.
Use proper markup to reference related settings.
Consistently format references to files, editor commands, command line
arguments, files, etc. as `code`.
Fix typos, add missing full-stops, add missing default values.
Configuration is editor-independent. For this reason, we pick
JSON-schema as the repr of the source of truth. We do specify it using
rust-macros and some quick&dirty hackery though.
The idea for syncing truth with package.json is to just do that
manually, but there's a test to check that they are actually synced.
There's CLI to print config's json schema:
$ rust-analyzer --print-config-schema
We go with a CLI rather than LSP request/response to make it easier to
incorporate the thing into extension's static config. This is roughtly
how we put the thing in package.json.
6496: Use builtin scopes more r=matklad a=georgewfraser
VSCode has added more builtin fallback scopes, so we can remove some of our fallback scopes by aligning with their conventions.
Note that the macro scope doesn't seem to actually *work* at the moment. I have filed a bug with VSCode: https://github.com/microsoft/vscode/issues/110150
Co-authored-by: George Fraser <george@fivetran.com>
* Chalk very recently (like an hour ago) merged a fix that prevents rust analyzer from panicking. This allows it to be usable again for code that hits those situations. See #6134, #6145, Probably #6120
5985: Make MergeBehaviour configurable r=jonas-schievink a=Veykril
This should make the newly implemented `MergeBehaviour` for import insertion configurable as roughly outlined in https://github.com/rust-analyzer/rust-analyzer/pull/5935#issuecomment-685834257. For the config name and the like I just picked what came to mind so that might be up for bikeshedding.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
4602: Add boolean literal semantic token type to package.json r=matklad a=lnicola
Closes#4583.
CC @GrayJack
4603: Add self keyword semantic token type r=matklad a=lnicola
Not sure if this is warranted a new token type or just a modifier.
---
CC #4583, @GrayJack
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
4499: CodeLens configuration options r=vsrs a=vsrs
This PR
- adds an option to granularly enable\disable all CodeLens, just like the TypeScript extension.
- fixes a minor bug for doctests. It makes no sense to show `Debug` lens for them as cargo `Can't skip running doc tests with --no-run`.
Co-authored-by: vsrs <vit@conrlab.com>
4448: Generate configuration for launch.json r=vsrs a=vsrs
This PR adds two new commands: `"rust-analyzer.debug"` and `"rust-analyzer.newDebugConfig"`. The former is a supplement to the existing `"rust-analyzer.run"` command and works the same way: asks for a runnable and starts new debug session. The latter allows adding a new configuration to **launch.json** (or to update an existing one).
If the new option `"rust-analyzer.debug.useLaunchJson"` is set to true then `"rust-analyzer.debug"` and Debug Lens will first look for existing debug configuration in **launch.json**. That is, it has become possible to specify startup arguments, env variables, etc.
`"rust-analyzer.debug.useLaunchJson"` is false by default, but it might be worth making true the default value. Personally I prefer true, but I'm not sure if it is good for all value.
----
I think that this PR also solves https://github.com/rust-analyzer/rust-analyzer/issues/3441.
Both methods to update launch.json mentioned in the issue do not work:
1. Menu. It is only possible to add a launch.json configuration template via a debug adapter. And anyway it's only a template and it is impossible to specify arguments from an extension.
2. DebugConfigurationProvider. The exact opposite situation: it is possible to specify all debug session settings, but it is impossible to export these settings to launch.json.
Separate `"rust-analyzer.newDebugConfig"` command looks better for me.
----
Fixes#4450Fixes#3441
Co-authored-by: vsrs <vit@conrlab.com>
Co-authored-by: vsrs <62505555+vsrs@users.noreply.github.com>
4166: Defining a default target to support cross-compilation targets r=matklad a=FuriouZz
Related to #4163
Co-authored-by: Christophe MASSOLIN <christophe.massolin@gmail.com>
The `workspaceLoaded` notification setting was originally designed to
control the display of a popup message that said:
"workspace loaded, {} rust packages"
This popup was removed and replaced by a much sleeker message in the
VSCode status bar that provides a real-time status while loading:
rust-analyzer: {}/{} packages
This was done as part of #3587
The new status-bar indicator is unobtrusive and shouldn't need to be
disabled. So this setting is removed.
4222: Introduce C/C++ for Visual Studio Code extension as an alternative debug engine for Debug Code lens. r=matklad a=vsrs
At the moment Debug Code Lens can use only one debug engine: lldb via [CodeLLDB](https://marketplace.visualstudio.com/items?itemName=vadimcn.vscode-lldb) extension.
This PR adds support of the debug engine from the [MS C++ tools](https://marketplace.visualstudio.com/items?itemName=ms-vscode.cpptools) extension, as well as the configuration option. If both extensions are installed, `CodeLLDB` will be used by default.
Another new option `rust-analyzer.debug.sourceFileMap` allows, for example, to step into Rust std library during debugging. Works only with `MS C++ tools`.
On Windows:
```json
"rust-analyzer.debug.sourceFileMap": {
"/rustc/4fb7144ed159f94491249e86d5bbd033b5d60550": "${env:USERPROFILE}/.rustup/toolchains/stable-x86_64-pc-windows-msvc/lib/rustlib/src/rust"
}
```
On Linux:
```json
"rust-analyzer.debug.sourceFileMap": {
"/rustc/4fb7144ed159f94491249e86d5bbd033b5d60550": "~/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust"
}
```
Co-authored-by: vsrs <vit@conrlab.com>
This is a quick way to implement unresolved reference diagnostics.
For example, adding to VS Code config
"editor.tokenColorCustomizationsExperimental": {
"unresolvedReference": "#FF0000"
},
will highlight all unresolved refs in red.
This is covered under vscode's "editor.semanticHighlighting.enabled"
setting plus the user has to have a theme that has opted into highlighting.
Bumps required vscode stable to 1.44
In textmate, keyword.control is used for all kinds of things; in fact,
the default scope mapping for keyword is keyword.control!
So let's add a less ambiguous controlFlow modifier
See Microsoft/vscode#94367
After refactoring the config we forgot to set defaults for
some properties like workspaceLoaded, callInfo.full, etc.
This commit restored them to being turned on by defult,
as well added defaults for other props to be more explicit
on their defualt value.
3817: vscode: highlight syntax tree ro editor r=matklad a=Veetaha
Small textmate grammar declaration to make rust-analyzer syntax tree more easily inspectable:
Btw, if we change the file extension of our `ra_syntax/test_data/**` files to `.rast` they should be highlighted in vscode too.
The colors of the tokens are actually going to be color-theme dependent, or you can customize them via:
```jsonc
{
"editor.tokenColorCustomizations": {
"textMateRules": [ { "scope": "name", "settings": { /* */ } } ]
}
}
```
Related: #3682
Co-authored-by: veetaha <veetaha2@gmail.com>
3629: Alternative aproach to plugin auto update r=matklad a=matklad
This is very much WIP (as in, I haven't run this once), but I like the result so far.
cc @Veetaha
The primary focus here on simplification:
* local simplification of data structures and control-flow: using union of strings instead of an enum, using unwrapped GitHub API responses
* global simplification of control flow: all logic is now in `main.ts`, implemented as linear functions without abstractions. This is stateful side-effective code, so arguments from [Carmack](http://number-none.com/blow/john_carmack_on_inlined_code.html) very much apply. We need all user interractions, all mutations, and all network requests to happen in a single file.
* as a side-effect of condensing everything to functions, we can get rid of various enums. The enums were basically a reified control flow:
```
enum E { A, B }
fn foo() -> E {
if cond { E::A } else { E::B }
}
fn bar(e: E) {
match e {
E::A => do_a(),
E::B => do_b(),
}
}
==>>
fn all() {
if cond { do_a() } else { do_b() }
}
```
* simplification of model: we don't need to reinstall on settings update, we can just ask the user to reload, we don't need to handle nightly=>stable fallback, we can ask the user to reinstall extension, (todo) we don't need to parse out the date from the version, we can use build id for nightly and for stable we can write the info directly into package.json.
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
Everything now happens in main.ts, in the bootstrap family of
functions. The current flow is:
* check everything only on extension installation.
* if the user is on nightly channel, try to download the nightly
extension and reload.
* when we install nightly extension, we persist its release id, so
that we can check if the current release is different.
* if server binary was not downloaded by the current version of the
extension, redownload it (we persist the version of ext that
downloaded the server).
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>
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)
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>
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>
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>
2061: Theme loading and "editor.tokenColorCustomizations" support. r=matklad a=seivan
Fixes: [Issue#1294](https://github.com/rust-analyzer/rust-analyzer/issues/1294#issuecomment-497450325)
TODO:
- [x] Load themes
- [x] Load existing `ralsp`-prefixed overrides from `"workbench.colorCustomizations"`.
- [x] Load overrides from `"editor.tokenColorCustomizations.textMateRules"`.
- [x] Use RA tags to load `vscode.DecorationRenderOptions` (colors) from theme & overrides.
- [x] Map RA tags to common TextMate scopes before loading colors.
- [x] Add default scope mappings in extension.
- [x] Cache mappings between settings updates.
- [x] Add scope mapping configuration manifest in `package.json`
- [x] Load configurable scope mappings from settings.
- [x] Load JSON Scheme for text mate scope rules in settings.
- [x] Update [Readme](https://github.com/seivan/rust-analyzer/blob/feature/themes/docs/user/README.md#settings).
Borrowed the theme loading (`scopes.ts`) from `Tree Sitter` with some modifications to reading `"editor.tokenColorCustomizations"` for merging with loaded themes and had to remove the async portions to be able to load it from settings updates.
~Just a PoC and an idea I toyed around with a lot of room for improvement.~
For starters, certain keywords aren't part of the standard TextMate grammar, so it still reads colors from the `ralsp` prefixed values in `"workbench.colorCustomizations"`.
But I think there's more value making the extension work with existing themes by maping some of the decoration tags to existing key or keys.
<img width="453" alt="Screenshot 2019-11-09 at 17 43 18" src="https://user-images.githubusercontent.com/55424/68531968-71b4e380-0318-11ea-924e-cdbb8d5eae06.png">
<img width="780" alt="Screenshot 2019-11-09 at 17 41 45" src="https://user-images.githubusercontent.com/55424/68531950-4b8f4380-0318-11ea-8f85-24a84efaf23b.png">
<img width="468" alt="Screenshot 2019-11-09 at 17 40 29" src="https://user-images.githubusercontent.com/55424/68531952-51852480-0318-11ea-800a-6ae9215f5368.png">
These will merge with the default ones coming with the extension, so you don't have to implement all of them and works well with overrides defined in settings.
```jsonc
"editor.tokenColorCustomizations": {
"textMateRules": [
{
"scope": "keyword",
"settings": {
"fontStyle": "bold",
}
},
]
},
```
Edit: The idea is to work with 90% of the themes out there by working within existing scopes available that are generally styled. It's not to say I want to erase the custom Rust scopes - those should still remain and eventually worked into a custom grammar bundle for Rust specific themes that target those, I just want to make it work with generic themes offered on the market place for now.
A custom grammar bundle and themes for Rust specific scopes is out of... scope for this PR.
We'll make another round to tackle those issues.
Current fallbacks implemented
```typescript
[
'comment',
[
'comment',
'comment.block',
'comment.line',
'comment.block.documentation'
]
],
['string', ['string']],
['keyword', ['keyword']],
['keyword.control', ['keyword.control', 'keyword', 'keyword.other']],
[
'keyword.unsafe',
['storage.modifier', 'keyword.other', 'keyword.control', 'keyword']
],
['function', ['entity.name.function']],
['parameter', ['variable.parameter']],
['constant', ['constant', 'variable']],
['type', ['entity.name.type']],
['builtin', ['variable.language', 'support.type', 'support.type']],
['text', ['string', 'string.quoted', 'string.regexp']],
['attribute', ['keyword']],
['literal', ['string', 'string.quoted', 'string.regexp']],
['macro', ['support.other']],
['variable', ['variable']],
['variable.mut', ['variable', 'storage.modifier']],
[
'field',
[
'variable.object.property',
'meta.field.declaration',
'meta.definition.property',
'variable.other'
]
],
['module', ['entity.name.section', 'entity.other']]
```
Co-authored-by: Seivan Heidari <seivan.heidari@icloud.com>
2583: Use prettier settings in ts-lint r=matklad a=edwin0cheng
This PR add `tslint-plugin-prettier` extension in ts-lint, which "runs prettier rules as tslint rules." and remove `quotemark` from ts-lint and let prettier to handle it.
And also fix#2515
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
2568: Add option to disable all-targets. r=matklad a=pftbest
Can be useful in embedded.
Co-authored-by: Vadzim Dambrouski <vadzim.dambrouski@promwad.com>
2571: Fixed a typo in settings r=matklad a=omerbenamram
@lnicola found a typo in the description for one of the settings introduced in #2559.
Co-authored-by: Omer Ben-Amram <omerbenamram@gmail.com>
1984: Bump rollup and vsce r=matklad a=kjeremy
I got sick of the vsce warning on install and noticed that rollup was also out of date.
Co-authored-by: kjeremy <kjeremy@gmail.com>
The old `vscode` package is outdated and it is recommened to switch to
these two new packages. This also solves a problem of a missing `.d.ts`
for `vscode` in Nixos.
This is actually much faster than I expected; it takes about 13 seconds
to download VS Code and run the unit tests. This means the VS Code tests
are still significantly faster than the Rust ones.
If this ends up being unreliable we can always remove it later or move
it to a separate optional job.
We also need to ignore the `.vscode-test` directory when running
`prettier` or it will get upset about some temporary JSON files VS Code
creates.
As promised in #1439 this is an initial attempt at unit testing the
VSCode extension. There are two separate parts to this: getting the test
framework working and unit testing the code in #1439.
The test framework nearly intact from the VSCode extension generator.
The main thing missing was `test/index.ts` which acts as an entry point
for Mocha. This was simply copied back in. I also needed to open the
test VSCode instance inside a workspace as our file URI generation
depends on a workspace being open.
There are two ways to run the test framework:
1. Opening the extension's source in VSCode, pressing F5 and selecting
the "Extensions Test" debug target.
2. Closing all copies of VSCode and running `npm test`. This is started
from the command line but actually opens a temporary VSCode window to
host the tests.
This doesn't attempt to wire this up to CI. That requires running a
headless X11 server which is a bit daunting. I'll assess the difficulty
of that in a follow-up branch. This PR is at least helpful for local
development without having to induce errors on a Rust project.
For the actual tests this uses snapshots of `rustc` output from a real
Rust project captured from the command line. Except for extracting the
`message` object and reformatting they're copied verbatim into fixture
JSON files.
Only four different types of diagnostics are tested but they represent
the main combinations of code actions and related information possible.
They can be considered the happy path tests; as we encounter
corner-cases we can introduce new tests fixtures.
Very simple approach: For each identifier, set the hash of the range
where it's defined as its 'id' and use it in the VSCode extension to
generate unique colors.
Thus, the generated colors are per-file. They are also quite fragile,
and I'm not entirely sure why. Looks like we need to make sure the
same ranges aren't overwritten by a later request?
This fixes#1005.
Defaults to `ask` which prompts users each time whether to start `cargo watch`
or not. `enabled` always starts `cargo watch` and `disabled` does not.
This allows users to control whether or not they want to see the "workspace
loaded" notification.
This is done on the server side using InitializationOptions which are provided
by the client. By default show_workspace_loaded is true, meaning the
notification is sent.
This enables the client to use a command to either show the live-updating
version of the syntax tree for the current file. Or optionally when a selected
range is provided, we then provide a snapshot of the syntax tree for the range.
This further fixes problems when having a VIM extension (at least vscodevim)
enabled, by not calling `overrideCommand('type', commands.onEnter.handle)` when
enableEnhancedTyping is set to `false`.
The problem is dependent on the order in which extensions are activated, if
rust-analyzer is activated before `vscodevim`, rust-analyzer will register the
`type` command, and when `vscodevim` finally attempts to activate, it will fail
to register the command. This causes `vscodevim` to stop working properly.
This setting allows users to disable the registerCommand `type` in
rust-analyzer, allowing `vscodevim` to work. The setting defaults to `true`.
Currently changing the setting requires reloading of the window.
Private stops npm publish working, which would be nonsensical anyway
In case it gets added to the vscode extension repository, preview marks it as such
Private may also prevent publishing to the vscode extension repository
