aboutsummaryrefslogtreecommitdiff
path: root/editors/code/src/utils/diagnostics
Commit message (Collapse)AuthorAgeFilesLines
* Remove cargo watch supporting code and tests from vscode extensionEmil Lauridsen2019-12-254-457/+0
|
* Add macro span handlingEdwin Cheng2019-12-181-0/+38
|
* Code: enable prettier trailing commasLaurențiu Nicola2019-12-094-16/+16
|
* Fixarsdragonfly2019-09-281-3/+1
|
* Fix testsarsdragonfly2019-09-271-2/+1
|
* Support the new deprecated tagarsdragonfly2019-09-271-1/+20
|
* Switch to `@types/vscode` and `vscode-test`Bastian Köcher2019-08-261-1/+1
| | | | | | 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.
* Merge #1459bors[bot]2019-06-301-0/+9
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-301-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* 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-294-0/+390
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.