aboutsummaryrefslogtreecommitdiff
path: root/editors
Commit message (Collapse)AuthorAgeFilesLines
* Switch to `@types/vscode` and `vscode-test`Bastian Köcher2019-08-266-450/+802
| | | | | | 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.
* implement feature flagsAleksey Kladov2019-08-223-5/+10
|
* fix default for the exlude keyAleksey Kladov2019-08-211-1/+1
|
* fix #1424xfoxfu2019-08-191-1/+9
| | | | resolve "~" in raLspServerPath
* Drop support for old extendSelection APIAleksey Kladov2019-08-121-29/+3
| | | | | | Emacs now handles this via native LSP request https://github.com/emacs-lsp/lsp-mode/commit/dc86bbb227147aa8141e690ad5648fdbd2ebdb9f
* Improvements to emacs inlay hintsFlorian Diebold2019-08-101-17/+24
| | | | | | - only send request if workspace is initialized (emacs-lsp doesn't seem to prevent sending requests before the initialized notification is sent) - check whether we're still in the correct buffer before sending request
* Merge #1652bors[bot]2019-08-062-41/+55
|\ | | | | | | | | | | | | | | | | | | | | | | 1652: Improve type hints behavior r=matklad a=SomeoneToIgnore This PR fixed the following type hints issues: * Restructures the `InlayKind` enum contents based on the discussion here: https://github.com/rust-analyzer/rust-analyzer/pull/1606#issuecomment-515968055 * Races described in #1639 * Caches the latest decorations received for each file to show them the next time the file is opened (instead of a new server request) Co-authored-by: Kirill Bulatov <[email protected]>
| * Avoid shared mutable stateKirill Bulatov2019-08-052-71/+55
| |
| * 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
| |
* | allow to exclude certain files and directoriesAleksey Kladov2019-08-063-1/+11
|/
* Merge #1614bors[bot]2019-07-291-1/+1
|\ | | | | | | | | | | | | | | 1614: show prettier diff on CI r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * show prettier diff on CIAleksey Kladov2019-07-291-1/+1
| |
* | Merge #1610bors[bot]2019-07-291-6/+11
|\ \ | | | | | | | | | | | | | | | | | | | | | 1610: Ignore cancelled inlay hints responses r=matklad a=SomeoneToIgnore Fixes #1607 Co-authored-by: Kirill Bulatov <[email protected]>
| * | Style fixesKirill Bulatov2019-07-291-1/+4
| | |
| * | Ignore cancelled inlay hints responsesKirill Bulatov2019-07-291-6/+8
| |/
* / :arrow_up: npmAleksey Kladov2019-07-292-110/+99
|/
* Implement inlay hints for emacsFlorian Diebold2019-07-271-3/+39
|
* npm run fixKirill Bulatov2019-07-252-10/+22
|
* Code review fixesKirill Bulatov2019-07-252-13/+13
|
* Remove unnecessary hacksKirill Bulatov2019-07-251-29/+0
|
* Fix linter issuesKirill Bulatov2019-07-253-32/+72
|
* Simplify the hints displayKirill Bulatov2019-07-252-54/+6
|
* Show type decoratorsKirill Bulatov2019-07-255-1/+175
|
* try to show exact prettier problemAleksey Kladov2019-07-251-1/+1
|
* :arrow_up: npm depsAleksey Kladov2019-07-252-10/+10
|
* Remove obsolete keybindingAleksey Kladov2019-07-211-5/+0
|
* underline mutable bindingsAleksey Kladov2019-07-192-30/+37
|
* highlight mutable variables differentlyEkaterina Babshukova2019-07-182-0/+10
|
* Bump lodash from 4.17.11 to 4.17.14 in /editors/codedependabot[bot]2019-07-121-3/+3
| | | | | | | Bumps [lodash](https://github.com/lodash/lodash) from 4.17.11 to 4.17.14. - [Release notes](https://github.com/lodash/lodash/releases) - [Commits](https://github.com/lodash/lodash/compare/4.17.11...4.17.14) Signed-off-by: dependabot[bot] <[email protected]>
* Update vsce to latestkjeremy2019-07-032-41/+42
|
* Merge #1458bors[bot]2019-06-302-1/+3
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | 1458: Run VS Code tests on CI r=matklad a=etaoins 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. cc @killercup Co-authored-by: Ryan Cumming <[email protected]>
| * Run VS Code tests on CIRyan Cumming2019-06-292-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | Merge #1459bors[bot]2019-06-303-1/+70
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1459: Include primary span label in VS Code diagnostics r=matklad a=etaoins In most cases the primary label span repeats information found elsewhere in the diagnostic. For example, with E0061: ```json { "message": "this function takes 2 parameters but 3 parameters were supplied", "spans": [{"label": "expected 2 parameters"}] } ``` However, with some mismatched type errors (E0308) the expected type only appears in the primary span's label, e.g.: ```json { "message": "mismatched types", "spans": [{"label": "expected usize, found u32"}] } ``` I initially added the primary span label to the message unconditionally. However, for most error types the child diagnostics repeat the primary span label with more detail. `rustc` also renders the duplicate text but because the span label and child diagnostics appear in visually distinct places it's not as confusing. This takes a heuristic approach where it will only add the primary span label if there are no child message lines. For most error types the child messages repeat the primary span label with more detail. Co-authored-by: Ryan Cumming <[email protected]>
| * | Include primary span label in VS Code diagnosticsRyan Cumming2019-06-303-1/+70
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In most cases the primary label span repeats information found elsewhere in the diagnostic. For example, with E0061: ``` { "message": "this function takes 2 parameters but 3 parameters were supplied", "spans": [{"label": "expected 2 parameters"}] } ``` However, with some mismatched type errors (E0308) the expected type only appears in the primary span's label, e.g.: ``` { "message": "mismatched types", "spans": [{"label": "expected usize, found u32"}] } ``` I initially added the primary span label to the message unconditionally. However, for most error types the child diagnostics repeat the primary span label with more detail. `rustc` also renders the duplicate text but because the span label and child diagnostics appear in visually distinct places it's not as confusing. This takes a heuristic approach where it will only add the primary span label if there are no child message lines.
* / Consider unreachable code to be unnecessary in VSCRyan Cumming2019-06-301-0/+1
|/ | | | | | This adds `unreachable_code` to the list of diagnostic codes we map to `Unnecessary` in Visual Studio Code. This is consistent with what the TypeScript language server does.
* Merge #1454bors[bot]2019-06-2910-254/+498
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1454: Fix `cargo watch` code action filtering r=etaoins a=etaoins 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. Co-authored-by: Ryan Cumming <[email protected]>
| * Comment on the key of `suggestedFixes`Ryan Cumming2019-06-291-0/+3
| | | | | | | | This isn't immediately obvious without looking at the users of the map
| * Fix `cargo watch` code action filteringRyan Cumming2019-06-2910-254/+495
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | Add noUnusedLocals to VsCode tsconfigRyan Cumming2019-06-292-2/+2
|/ | | | | | `tslint` doesn't catch this because TypeScript has had this check builtin since 2.9. However, it's disabled by default so right now nothing is checking for unused variables.
* Add show syntax tree function to emacszbelial2019-06-291-0/+26
|
* Extract lint scopes from `cargo watch`Ryan Cumming2019-06-263-6/+35
| | | | | | | | | | | Currently all of our VS Code diagnostics are given the source of `rustc`. However, if you have something like `cargo-watch.command` set to `clippy` it will also watch for Clippy lints. The `rustc` source is a bit misleading in that case. Fortunately, Rust's tool lints (RFC 2103) line up perfectly with VS Code's concept of `source`. This checks for lints scoped to a given tool and then splits them in to a `source` and tool-specific `code`.
* Initial Visual Studio Code unit testsRyan Cumming2019-06-2611-61/+765
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Tweak isUnusedOrUnnecessaryRyan Cumming2019-06-251-2/+8
| | | | | | | The first cut was a bit rough with the blanket `unused_*` rule. This trigger for things like `unused_mut` where the code is used but it's suboptimal. It's misleading to grey out the code in those cases. Instead, use an explicit list of things known to be dead code.
* 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-252-54/+352
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-244-15/+21
|
* Apply suggestions from code reviewAleksey Sidorov2019-06-242-4/+4
| | | Co-Authored-By: Aleksey Kladov <[email protected]>
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-05 13:49:01 +0100