]> git.lizzy.rs Git - rust.git/commit
Merge #1449
authorbors[bot] <26634292+bors[bot]@users.noreply.github.com>
Thu, 27 Jun 2019 07:48:36 +0000 (07:48 +0000)
committerbors[bot] <26634292+bors[bot]@users.noreply.github.com>
Thu, 27 Jun 2019 07:48:36 +0000 (07:48 +0000)
commitb13a217a8b975d037b50c1b0e15073eabba582f8
tree94c99ab8d8e18f113c559d304cba9c070c16ab1b
parent04a211ff6146d167a2bdf7d200df36468137591b
parente052ca9d614e946a6cea4875ae50c68d77088257
Merge #1449

1449: Swallow expected `rustfmt` errors r=matklad a=etaoins

My workflow in Visual Studio Code + Rust Analyzer has become:

1. Make a change to Rust source code using all the analysis magic

2. Save the file to trigger `cargo watch`. I have format on save enabled for all file types so this also runs `rustfmt`

3. Fix any diagnostics that `cargo watch` finds

Unfortunately if the Rust source has any syntax errors the act of saving will pop up a scary "command has failed" message and will switch to the "Output" tab to show the `rustfmt` error and exit code.

I did a quick survey of what other Language Servers do in this case. Both the JSON and TypeScript servers will swallow the error and return success. This is consistent with how I remember my workflow in those languages. The syntax error will show up as a diagnostic so it should be clear why the file isn't formatting.

I checked the `rustfmt` source code and while it does distinguish "parse errors" from "operational errors" internally they both result in exit status of 1. However, more catastrophic errors (missing `rustfmt`, SIGSEGV, etc) will return 127+ error codes which we can distinguish from a normal failure.

This changes our handler to log an info message and feign success if `rustfmt` exits with status 1.

Another option I considered was only swallowing the error if the formatting request came from format-on-save. However, the Language Server Protocol doesn't seem to distinguish those cases.

Co-authored-by: Ryan Cumming <etaoins@gmail.com>