aboutsummaryrefslogtreecommitdiff
path: root/editors/code/src/commands
Commit message (Collapse)AuthorAgeFilesLines
...
* Move parentModule to the new CtxAleksey Kladov2019-12-302-27/+27
|
* Refactor applySourceChangeAleksey Kladov2019-12-305-96/+31
|
* Move joinLines to the new CtxAleksey Kladov2019-12-302-20/+20
|
* Move matching brace to new CtxAleksey Kladov2019-12-302-28/+27
|
* More second command to CtxAleksey Kladov2019-12-302-2/+9
|
* Start new ctx moduleAleksey Kladov2019-12-302-7/+14
|
* SimplifyAleksey Kladov2019-12-301-32/+29
|
* Re-format VSCode extension changesEmil Lauridsen2019-12-251-15/+14
|
* Re-implement status display using LSP 3.15 progress eventEmil Lauridsen2019-12-251-0/+43
|
* Remove cargo-watch from vscode extension.Emil Lauridsen2019-12-252-355/+0
| | | | Still keeps tests around for reference when porting them to rust
* Protect against null as revealed by `npm test`kjeremy2019-12-201-2/+7
|
* Fix formattingVadzim Dambrouski2019-12-161-2/+1
|
* Add option to disable all-targets.Vadzim Dambrouski2019-12-151-1/+4
| | | | Can be useful in embedded.
* Enable noImplicitReturns option for vscode extensionTetsuharu OHZEKI2019-12-111-6/+8
|
* Enable noUnusedParameters option for vscode extensionTetsuharu OHZEKI2019-12-113-3/+3
|
* Code: enable prettier trailing commasLaurențiu Nicola2019-12-0913-88/+88
|
* Merge pull request #2297 from kiljacken/masterAleksey Kladov2019-11-201-13/+1
|\ | | | | Add fancy truncation of type hints.
| * Move type inlay hint truncation to language serverEmil Lauridsen2019-11-191-13/+1
| | | | | | | | | | | | | | | | | | | | | | | | This commit implements a general truncation framework for HirFormatter that keeps track of how much has been output so far. This information can then be used to perform truncation inside the language server, instead of relying on the client. Initial support is implemented for truncating types hints using the maxInlayHintLength server config option. The existing solution in the VSCode extension has been removed in favor of letting the server truncate type hints.
* | Minor fix for outpu text formatingEdwin Cheng2019-11-191-1/+1
| |
* | Use DocumentProvider instead of HoverEdwin Cheng2019-11-191-23/+58
| |
* | Change return type of expand_macroEdwin Cheng2019-11-191-5/+8
| |
* | Fix npm formattingEdwin Cheng2019-11-191-8/+8
| |
* | Add recursive expand in vscodeEdwin Cheng2019-11-192-0/+47
|/
* Fix formatoxalica2019-11-161-1/+3
|
* Check exit code of `cargo watch`oxalica2019-11-151-3/+3
|
* Handle errors when `cargo watch` failsoxalica2019-11-151-0/+5
|
* Merge #1980bors[bot]2019-10-231-1/+17
|\ | | | | | | | | | | | | | | 1980: Shorten inline type hints r=matklad a=detrumi Implements #1946 Co-authored-by: Wilco Kusee <[email protected]>
| * Do not truncate the rangeWilco Kusee2019-10-231-30/+10
| |
| * Make inlay hint length configurableWilco Kusee2019-10-181-14/+26
| |
| * Truncate hints longer than 20 charactersWilco Kusee2019-10-101-4/+28
| |
* | Adds config option for cargo-watch `--ignore` flagRoberto Vidal2019-10-171-1/+6
|/
* Replace watcher file existence check with vscode.fs versionLucas Spits2019-09-091-11/+10
|
* Avoid shared mutable stateKirill Bulatov2019-08-051-67/+39
|
* Cache decorations before the first change onlyKirill Bulatov2019-08-051-20/+21
|
* Use WeakMap to avoid memory leaksKirill Bulatov2019-08-051-10/+12
|
* Style and test fixesKirill Bulatov2019-08-041-6/+17
|
* Query less hints on file openKirill Bulatov2019-08-041-18/+34
|
* Style fixesKirill Bulatov2019-07-291-1/+4
|
* Ignore cancelled inlay hints responsesKirill Bulatov2019-07-291-6/+8
|
* npm run fixKirill Bulatov2019-07-251-1/+5
|
* Code review fixesKirill Bulatov2019-07-251-7/+7
|
* Remove unnecessary hacksKirill Bulatov2019-07-251-29/+0
|
* Fix linter issuesKirill Bulatov2019-07-252-29/+63
|
* Simplify the hints displayKirill Bulatov2019-07-251-53/+6
|
* Show type decoratorsKirill Bulatov2019-07-252-1/+145
|
* Fix `cargo watch` code action filteringRyan Cumming2019-06-291-46/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | There are two issues with the implementation of `provideCodeActions` introduced in #1439: 1. We're returning the code action based on the file its diagnostic is in; not the file the suggested fix is in. I'm not sure how often fixes are suggested cross-file but it's something we should handle. 2. We're not filtering code actions based on the passed range. The means if there is any suggestion in a file we'll show an action for every line of the file. I naively thought that VS Code would filter for us but that was wrong. Unfortunately the VS Code `CodeAction` object is very complex - it can handle edits across multiple files, run commands, etc. This makes it complex to check them for equality or see if any of their edits intersects with a specified range. To make it easier to work with suggestions this introduces a `SuggestedFix` model object and a `SuggestFixCollection` code action provider. This is a layer between the raw Rust JSON and VS Code's `CodeAction`s. I was reluctant to introduce another layer of abstraction here but my attempt to work directly with VS Code's model objects was worse.
* Initial Visual Studio Code unit testsRyan Cumming2019-06-261-61/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Fix comparison of Code Action edit lengthsRyan Cumming2019-06-251-1/+1
| | | | | This happened to work because we always produce a single edit but this is obviously dubious.
* Rich mapping of cargo watch outputRyan Cumming2019-06-251-54/+132
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently we depend on the ASCII rendering string that `rustc` provides to populate Visual Studio Code's diagnostic. This has a number of shortcomings: 1. It's not a very good use of space in the error list 2. We can't jump to secondary spans (e.g. where a called function is defined) 3. We can't use Code Actions aka Quick Fix This moves all of the low-level parsing and mapping to a `rust_diagnostics.ts`. This uses some heuristics to map Rust diagnostics to VsCode: 1. As before, the Rust diagnostic message and primary span is used for the root diagnostic. However, we now just use the message instead of the rendered version. 2. Every secondary span is converted to "related information". This shows as child in the error list and can be jumped to. 3. Every child diagnostic is categorised in to three buckets: 1. If they have no span they're treated as another line of the root messages 2. If they have replacement text they're treated as a Code Action 3. If they have a span but no replacement text they're treated as related information (same as secondary spans).
* Fix code after "apply suggestions"Aleksei Sidorov2019-06-242-5/+11
|