aboutsummaryrefslogtreecommitdiff
path: root/editors/code/src/commands
Commit message (Collapse)AuthorAgeFilesLines
* Introduce `toggle inlay hints` vscode commandveetaha2020-05-252-0/+12
| | | | | | | | Users now can assign a shortcut for this command via the general vscode keybindings ui or `keybinding.json file` Closes: #4599
* Document matchingBrace LSP requestAleksey Kladov2020-05-241-2/+2
|
* CodeAction groupsAleksey Kladov2020-05-221-9/+5
|
* Use WorkspaceEdit for ssrAleksey Kladov2020-05-211-4/+2
|
* Formalize JoinLines protocol extensionAleksey Kladov2020-05-211-4/+8
|
* Transition OnEnter to WorkspaceSnippetEditAleksey Kladov2020-05-212-29/+51
| | | | | | | | This also changes our handiling of snippet edits on the client side. `editor.insertSnippet` unfortunately forces indentation, which we really don't want to have to deal with. So, let's just implement our manual hacky way of dealing with a simple subset of snippets we actually use in rust-analyzer
* Fix client-side snippetsAleksey Kladov2020-05-191-1/+2
|
* Implement client-side of SnippetTextEditAleksey Kladov2020-05-191-0/+34
|
* code formattingvsrs2020-05-171-1/+1
|
* Runnable QuickPick with debuggees onlyvsrs2020-05-171-3/+14
|
* Merge #4448bors[bot]2020-05-151-98/+103
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 #4450 Fixes #3441 Co-authored-by: vsrs <[email protected]> Co-authored-by: vsrs <[email protected]>
| * Runnable quick pick with buttonsvsrs2020-05-141-21/+61
| |
| * "rust-analyzer.newDebugConfig" commandvsrs2020-05-111-1/+29
| |
| * "rust-analyzer.debug" commandvsrs2020-05-111-106/+43
| |
* | Make some stuff public so that they can be reused by other toolsPavan Kumar Sunkara2020-05-141-1/+1
| |
* | Merge #4083bors[bot]2020-05-131-1/+1
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | 4083: Smol documentation for ast nodes r=matklad a=Veetaha There is a tremendous amount of TODOs to clarify the topics I am not certain about. Please @matklad, @edwin0cheng review carefully, I even left some mentions of your names in todos to put your attention where you most probably can give comments. In order to simplify the review, I separated the codegen (i.e. changes in `ast/generated/nodes.rs`) from `ast_src` changes (they in fact just duplicate one another) into two commits. Also, I had to hack a little bit to let the docs be generated as doc comments and not as doc attributes because it's easier to read them this way and IIRC we don't support hints for `#[doc = ""]` attributes for now... Closes #3682 Co-authored-by: veetaha <[email protected]>
| * Fix "show syntax tree" commandveetaha2020-05-101-1/+1
| | | | | | | | @matlkad please don't forget to keep it up-to-date!
* | Word fixEdwin Cheng2020-05-101-1/+1
|/
* Add CodeLLDB Rust visualizationvsrs2020-05-071-1/+2
|
* Add separate settings for each debug engine.vsrs2020-05-071-3/+6
|
* Add additional debug optionsvsrs2020-05-071-3/+9
|
* Uniformed way to get Debug Lens target executable.vsrs2020-05-061-26/+33
|
* Removed unnecessary extraArgs for cargo invocationvsrs2020-04-301-1/+1
|
* Fixed tsfmt and eslint errors.vsrs2020-04-301-7/+7
|
* pass Cargo errors to the Debug output channelvsrs2020-04-301-1/+6
|
* MS C++ tools on linuxvsrs2020-04-291-1/+2
|
* better configuration enum itemsvsrs2020-04-291-1/+1
|
* Configuration settings and source maps supportvsrs2020-04-291-8/+25
|
* ms-vscode.cpptools debugger support, initial version.vsrs2020-04-281-12/+35
|
* Refactor the workaround a bitveetaha2020-04-221-19/+16
|
* Work around crlf in syntax treeveetaha2020-04-221-2/+38
|
* Remove vscode_lldb settingAleksey Kladov2020-04-021-0/+4
|
* vscode: postrefactorveetaha2020-04-021-12/+6
|
* vscode: postrefactor variable namesveetaha2020-04-021-8/+8
|
* vscode: add goto definition from rust file to syntax tree editorveetaha2020-04-021-5/+83
|
* Merge #3817bors[bot]2020-04-021-1/+4
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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": { /* */ } } ] } } ``` ![image](https://user-images.githubusercontent.com/36276403/78204947-99f9d600-74a3-11ea-8315-cb1c87810c7c.png) Related: #3682 Co-authored-by: veetaha <[email protected]>
| * vscode: add highlighting of syntax treeveetaha2020-04-021-1/+4
| |
* | vscode: add support for light themes and color customization for syntax tree ↵veetaha2020-04-011-2/+4
|/ | | | highlights
* vscode: small refactorveetaha2020-03-311-1/+1
|\
| * vscode: apply review nitsVeetaha2020-03-311-1/+1
| |
* | vscode: scroll to the syntax node in rust editor when highlightingveetaha2020-03-311-1/+2
|/
* vscode: use ctx.subscriptions instead of local .disposablesveetaha2020-03-311-15/+12
|
* vscode: add syntax tree inspection hovers and highlightsveetaha2020-03-311-53/+116
|
* vscode: fix release tag retrievalVeetaha2020-03-271-1/+1
| | | Co-Authored-By: Laurențiu Nicola <[email protected]>
* vscode: show release tag with along with the commit hash for RA version commandveetaha2020-03-261-2/+7
|
* vscode: refactor analyzer statusveetaha2020-03-251-20/+11
|
* Rewrite auto-updateAleksey Kladov2020-03-191-13/+3
| | | | | | | | | | | | | | 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).
* Separate persistent mutable state from configAleksey Kladov2020-03-161-1/+1
| | | | | That way, we clearly see which things are not change, and we also clearly see which things are persistent.
* Merge #3534bors[bot]2020-03-161-2/+1
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3534: Feature: vscode impl nightlies download and installation r=Veetaha a=Veetaha I need to test things more, but the core shape of the code is quite well-formed. The main problem is that we save the release date only for nightlies and there are no means to get the release date of the stable extension (i.e. for this we would need to consult the github releases via a network request, or we would need to somehow save this info into package.json or any other file accessible from the extension code during the deployment step, but this will be very hard I guess). So there is an invariant that the users can install nightly only from our extension and they can't do it manually, because when installing the nightly `.vsix` we actually save its release date to `globalState` Closes: #3402 TODO: - [x] More manual tests and documentation cc @matklad @lnicola Co-authored-by: Veetaha <[email protected]> Co-authored-by: Veetaha <[email protected]>
| * vscode: amend server installation logic to account for nightliesVeetaha2020-03-141-2/+1
| |
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-08 00:04:18 +0100