- remove comment scope from ignored params
- underscores will automatically receive variable/param scope
- add raw ID syntax to modules, functions, and variables
6251: Semantic Highlight: Add Callable modifier for variables r=matklad a=GrayJack
This PR added the `HighlightModifier::Callable` variant and assigned it to variables and parameters that are fn pointers, closures and implements FnOnce trait.
This allows to colorize these variables/parameters when used in call expression.
6310: Rewrite algo::diff to support insertion and deletion r=matklad a=Veykril
This in turn also makes `algo::diff` generate finer diffs(maybe even minimal diffs?) as insertions and deletions aren't always represented as as replacements of parent nodes now.
Required for #6287 to go on.
Co-authored-by: GrayJack <gr41.j4ck@gmail.com>
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
6274: Check cargoExtraArgs for undefined before using r=matklad a=feileacan
Fixes#6273
Co-authored-by: feileacan <54381366+feileacan@users.noreply.github.com>
6137: add a new TextMate grammar r=matklad a=dustypomerleau
Thanks to everyone working hard on Rust Analyzer - my impression is that it's quickly becoming the community default.
I think it would be helpful to have a more robust TextMate grammar to fall back on, for those who wish to disable semantic highlighting for any reason. It should allow theming of punctuation, and provide scopes for all tokens on the page. This can be done at zero cost to those who enable semantic highlighting, as the TextMate scopes will be invisible to those users.
I can see a couple ways of accomplishing this:
1. Ship a new grammar by merging this PR.
1. Ship no TextMate grammar at all (like the [Rust](https://marketplace.visualstudio.com/items?itemName=rust-lang.rust) extension), and allow users to install a separate extension that provides the grammar of their choice (I have released this one as [Rust Syntax](https://marketplace.visualstudio.com/items?itemName=dustypomerleau.rust-syntax)). If no grammar were installed, they would simply fall back to the default grammar provided by their editor. In the case of VS Code, the default grammar already matches what is currently being shipped, so users who choose not to override it would see no difference.
I have tried to choose sensible default scopes, in the hopes that a wider variety of themes would work out of the box with Rust, even if those themes do not yet supply scopes for semantic highlighting. There is definitely some interest in using this grammar with Rust Analyzer, as this was the very first issue after the syntax extension was shipped: https://github.com/dustypomerleau/rust-syntax/issues/1.
I considered simply using an alternative grammar alongside Rust Analyzer, but this doesn't seem possible. When RA starts, any existing grammar/extension is overridden, and I haven't been able to find a workaround.
Co-authored-by: Dusty Pomerleau <dustypomerleau@users.noreply.github.com>
Currently a method only has defaultness if it is a provided trait
method, but this will change when specialisation is available and may
need to become a concept known to hir.
I opted to go for a 'fewest changes' approach given specialisation is
still under development.
* 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
The previous version would have interpreted an empty token as
an abort of the dialog and would have not properly cleared the token.
This is now fixed by checking for `undefined` for a an abort and
by setting the token to `undefined` in order to clear it.
This change allows to use a authorization token provided by Github in
order to fetch metadata for a RA release. Using an authorization token
prevents to get rate-limited in environments where lots of RA users use
a shared client IP (e.g. behind a company NAT).
The auth token is stored in `ExtensionContext.globalState`.
As far as I could observe through testing with a local WSL2 environment
that state is synced between an extension installed locally and a remote
version.
The change provides no explicit command to query for an auth token.
However in case a download fails it will provide a retry option as well
as an option to enter the auth token. This should be more discoverable
for most users.
Closes#3688
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>
5910: Fix some typos r=matklad a=SomeoneToIgnore
5912: Remove fixme from inlay_hints.ts r=matklad a=Veetaha
I have reevaluated the fixme and it doesn't seem necessary to pass an array of files
to the inlay hints request.
This will (a) make the request more compilcated (b), make us wait for
inlay hints for `all` active editors resolve at once before rendering and (c)
doesn't seem required because 99% of the time there is a single active editor
in the IDE
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
Co-authored-by: Veetaha <veetaha2@gmail.com>
I have reevaluated the fixme and it doesn't seem necessary to pass an array of files
to the inlay hints request.
This will (a) make the request more compilcated (b), make us wait for
inlay hints for `all` active editors resolve at once before rendering and (c)
doesn't seem required because 99% of the time there is a single active editor
in the IDE
5682: Add an option to disable diagnostics r=matklad a=popzxc
As far as I know, currently it's not possible to disable a selected type of diagnostics provided by `rust-analyzer`.
This causes an inconvenient situation with a false-positive warnings: you either have to disable all the diagnostics, or you have to ignore these warnings.
There are some open issues related to this problem, e.g.: https://github.com/rust-analyzer/rust-analyzer/issues/5412, https://github.com/rust-analyzer/rust-analyzer/issues/5502
This PR attempts to make it possible to selectively disable some diagnostics on per-project basis.
Co-authored-by: Igor Aleksanov <popzxc@yandex.ru>
5776: Fix eslint errors on .eslintrc.js and rollup.config.js r=matklad a=fuafa
Eslint complains if these two files does not include in the `tsconfig.json`.
```
Parsing error: "parserOptions.project" has been set for @typescript-eslint/parser.
The file does not match your project config: .eslintrc.js.
The file must be included in at least one of the projects provided.eslint
```
5780: Fixup whitespace when adding missing impl items r=matklad a=jDomantas
Generate properly formatted whitespace when adding impl items - with an empty line between items and removing extra whitespace that often appears at the end.
This is my first time working on rust analyzer so I'm not very familiar with its internal APIs. If there's a better way to do such syntax tree editing I'd be glad to hear it.
Co-authored-by: xiaofa <xiaofalzx@gmail.com>
Co-authored-by: jDomantas <djadenkus@gmail.com>
No we return ContentModified during the workspace loading. This signifies the language
client to retry the operation (i.e. the client will
continue polling the server while it returns ContentModified).
I believe that there might be cases of overly big projects where the backoff
logic we have setup in `sendRequestWithRetry` (which we use for inlay hints)
might bail too early (currently the largest retry standby time is 10 seconds).
However, I've tried on one of my project with 500+ dependencies and it is still enough.
5513: Try figure out correct workspace in vscode multi root workspace r=vsrs a=urbandove
the code to replace the root with the `${workspaceRoot}` arg breaks in multi root workspaces as it needs a qualifier `${workspaceRoot:workspaceName}`
This PR attempts to figure out the root workspace - and if it cant find it falls back to the first workspace
Co-authored-by: Urban Dove <urbandove80@gmail.com>
5480: Fix snippetTextEdits applying to other files r=matklad a=TimoFreiberg
Fixes#4551
`vscode.window.visibleTextEditors` only contains editors whose contents are being displayed at the moment, so the previous logic only worked if the other file for which a snippetTextEdit is being received was visible in a separate split.
I feel that this is a hacky approach, so feel free to reject it for something nicer :)
Co-authored-by: Timo Freiberg <timo.freiberg@gmail.com>
vscode.window.visibleTextEditors only contains editors whose contents
are being displayed at the moment, so the previous logic only worked if
the other file for which a snippetTextEdit is being received was visible
in a separate split.
Co-authored-by: bjorn3 <bjorn3@users.noreply.github.com>
Override miniz_oxide to build it with optimizations
Building this crate with optimizations decreases the gzipping
part of `cargo xtask dist` from `30-40s` down to `3s`,
the overhead for `rustc` to apply optimizations is miserable on this background
5202: Runnable env r=matklad a=vsrs
This PR adds on option to specify (in the settings.json) environment variables passed to the runnable.
The simplest way for all runnables in a bunch:
```jsonc
"rust-analyzer.runnableEnv": {
"RUN_SLOW_TESTS": "1"
}
```
Or it is possible to specify vars more granularly:
```jsonc
"rust-analyzer.runnableEnv": [
{
// "mask": null, // null mask means that this rule will be applied for all runnables
env: {
"APP_ID": "1",
"APP_DATA": "asdf"
}
},
{
"mask": "test_name",
"env": {
"APP_ID": "2", // overwrites only APP_ID
}
}
]
```
You can use any valid RegExp as a mask. Also note that a full runnable name is something like *run bin_or_example_name*, *test some::mod::test_name* or *test-mod some::mod*, so it is possible to distinguish binaries, single tests, and test modules with this masks: `"^run"`, `"^test "` (the trailing space matters!), and `"^test-mod"` respectively.
Fixes#4450
I suppose this info should be somewhere in the docs, but unsure where is the best place.
Co-authored-by: vsrs <vit@conrlab.com>
