rust-analyzer - [FORK] modified to work on wasm targets

	Commit message (Collapse)	Author	Age	Files	Lines
*	Enable noImplicitReturns option for vscode extension	Tetsuharu OHZEKI	2019-12-11	3	-5/+10
\|
*	Code: enable prettier trailing commas	Laurențiu Nicola	2019-12-09	5	-62/+62
\|
*	Fix tests	arsdragonfly	2019-09-27	1	-4/+4
\|
*	Switch to `@types/vscode` and `vscode-test`	Bastian Köcher	2019-08-26	1	-0/+49
\| \| \| \| \| \|	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.
*	Include primary span label in VS Code diagnostics	Ryan Cumming	2019-06-30	1	-1/+28
\| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \|	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.
*	Fix `cargo watch` code action filtering	Ryan Cumming	2019-06-29	4	-0/+529
	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.