diff options
author | bors[bot] <26634292+bors[bot]@users.noreply.github.com> | 2019-06-29 10:50:56 +0100 |
---|---|---|
committer | bors[bot] <26634292+bors[bot]@users.noreply.github.com> | 2019-06-29 10:50:56 +0100 |
commit | 8865db6768fd913b971df56fc0bcf7439fcb1e71 (patch) | |
tree | 3fff3954f7f5ca0c6045f9f7d96c1cd75bd896ee /crates/gen_lsp_server | |
parent | 64f71dd3fff7b902656a2c2465a1b5071b2b1903 (diff) | |
parent | 50c6ab709e38b63fb1e3ee5db40426ef131cbd71 (diff) |
Merge #1454
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]>
Diffstat (limited to 'crates/gen_lsp_server')
0 files changed, 0 insertions, 0 deletions