aboutsummaryrefslogtreecommitdiff
path: root/editors/code/src
Commit message (Collapse)AuthorAgeFilesLines
* Merge pull request #2297 from kiljacken/masterAleksey Kladov2019-11-202-13/+2
|\ | | | | Add fancy truncation of type hints.
| * Move type inlay hint truncation to language serverEmil Lauridsen2019-11-192-13/+2
| | | | | | | | | | | | | | | | | | | | | | | | 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-192-33/+70
| |
* | Change return type of expand_macroEdwin Cheng2019-11-191-5/+8
| |
* | Fix npm formattingEdwin Cheng2019-11-192-14/+14
| |
* | Add recursive expand in vscodeEdwin Cheng2019-11-193-5/+62
|/
* 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
|
* Add link to the vscode VIM extension compatibility warning.krk2019-10-301-1/+1
|
* document feature flagsAleksey Kladov2019-10-252-9/+0
|
* Merge #1980bors[bot]2019-10-232-1/+23
|\ | | | | | | | | | | | | | | 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-182-14/+32
| |
| * Truncate hints longer than 20 charactersWilco Kusee2019-10-101-4/+28
| |
* | Adds config option for cargo-watch `--ignore` flagRoberto Vidal2019-10-172-2/+16
|/
* Fixarsdragonfly2019-09-281-3/+1
|
* Fix testsarsdragonfly2019-09-272-6/+5
|
* Support the new deprecated tagarsdragonfly2019-09-271-1/+20
|
* Replace watcher file existence check with vscode.fs versionLucas Spits2019-09-091-11/+10
|
* add option to disable notifyAleksey Kladov2019-09-062-0/+5
|
* Switch to `@types/vscode` and `vscode-test`Bastian Köcher2019-08-264-23/+72
| | | | | | 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-222-1/+6
|
* fix #1424xfoxfu2019-08-191-1/+9
| | | | resolve "~" in raLspServerPath
* 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-062-1/+6
|/
* Style fixesKirill Bulatov2019-07-291-1/+4
|
* Ignore cancelled inlay hints responsesKirill Bulatov2019-07-291-6/+8
|
* 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-254-1/+161
|
* underline mutable bindingsAleksey Kladov2019-07-191-27/+34
|
* highlight mutable variables differentlyEkaterina Babshukova2019-07-181-0/+1
|
* 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-291-1/+0
|/ | | | | | `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.
* 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`.
generated by cgit v1.2.3 (git 2.25.1) at 2024-09-13 20:11:29 +0100