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.
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).
Very simple approach: For each identifier, set the hash of the range
where it's defined as its 'id' and use it in the VSCode extension to
generate unique colors.
Thus, the generated colors are per-file. They are also quite fragile,
and I'm not entirely sure why. Looks like we need to make sure the
same ranges aren't overwritten by a later request?
As tested by @edwin0cheng, Windows requires the quotes removed in the
previous commit. This commit re-adds the quotes gated by an if statement
on the node environment, so that quotes are only added on Windows.
As of #1079 the VSCode cargo-watch functionality has been broken on
Linux systems.
The cause seems to be that linux takes the added quotes inside process
arguments literally, so it attempts to make cargo-watch run the command
`cargo "check --message-format json"` with the entire quoted part being
treated as a single long subcommand, which cargo doesn't know how to
handle.
Removing the extra quotes solves the issue.
This fixes#1005.
Defaults to `ask` which prompts users each time whether to start `cargo watch`
or not. `enabled` always starts `cargo watch` and `disabled` does not.
