mirror of
https://github.com/facebook/sapling.git
synced 2024-12-29 08:02:24 +03:00
8c724108fb
Summary:
tl;dr Got things working again by ignoring the `--config-path` from rls.
Despite my efforts in D17089540, `rustfmt` appeared to have stopped
working again in VS Code. I thought maybe something changed in our move
to 1.38.0-beta.3. I saw something about a `VersionMismatch` in the
console (which was the issue last time), but unfortunately the error
did not include what the expected and observed versions were, so I
built `rustfmt` from source locally and modified it to include this
information (which I should try to upstream).
Unfortunately, our VS Code/rls setup is not great when it comes to
logging errors to a file, so once again I ran:
```
sudo execsnoop.py -n rust
```
and observed the external `rustfmt` command that `rls` ultimately
constructed and executed so I would have a simpler repro case.
Incidentally, after rls had a `rustfmt` error of some sort, it seemed
to end up in a broken state, so debugging the issue outside of rls
was a lot simpler. Anyway, here was an example of such a command I saw
from `execsnoop`:
```
/data/users/mbolin/eden-fbsource/fbcode/common/rust/tools/common/rustfmt_wrapper.sh --unstable-features --skip-children --emit stdout --quiet --config-path /dev/shm/tmp/i0gVWxrcpp
```
As explained in D17089540, `/dev/shm/tmp/i0gVWxrcpp` ends up being this
fully serialized `rustfmt` configuration. I took this command and repro'd
by making a local formatting error and piping the file in:
```
/data/users/mbolin/eden-fbsource/fbcode/common/rust/tools/common/rustfmt_wrapper.sh --unstable-features --skip-children --emit stdout --quiet --config-path /dev/shm/tmp/i0gVWxrcpp < scm/dotslash/src/main.rs | head
```
and got:
```
Warning for license template file "": No such file or directory (os error 2)
1 282 282
// Copyright 2004-present Facebook. All Rights Reserved.
mod backend;
mod config;
#[cfg(not(build = "instrumentation"))]
mod curl;
mod curl_args;
mod decompress;
mod dotslash_cache;
```
What was that garbage at the top about a license template file? I ended up
looking at `/dev/shm/tmp/i0gVWxrcpp` and found this line:
```
license_template_path = ""
```
Apparently the default value for this configuration option is `""`
and `rustfmt` tries to open the path without bothering to check whether
it is the empty string:
4449250539/src/config/license.rs (L215-L221)
Great. (I filed an issue for this at https://github.com/rust-lang/rustfmt/issues/3802.)
It finally dawned on me that between `required_version` and `license_template_path`,
this generated config file from rls was not doing us any favors. Since we are already
using `rustfmt_wrapper.sh` to rewrite some options that we care about, why not rewrite
`--config-path` to use the `.rustfmt.toml` config in fbcode?
So that's what I did and now everything seems to work again.
Also, I appeared to have figured out why we need a wrapper script in the first place!
rls tries to set the `emit_mode` to `ModifiedLines`, which would generate the output
from rustfmt in the way that rls wants. It looks like someone then made reading from
stdin incompatible with `emit_mode=ModifiedLines`. I filed this as:
https://github.com/rust-lang/rls/issues/1555
Reviewed By: dtolnay
Differential Revision: D17492254
fbshipit-source-id: 3415bdab3c1030d3082ae2b8fab0c2e6b312534a
11 lines
304 B
TOML
11 lines
304 B
TOML
# Get help on options with `rustfmt --help=config`
|
|
# Please keep these in alphabetical order.
|
|
# Prefer to keep builtin and custom derives separate
|
|
edition = "2018"
|
|
merge_derives = false
|
|
reorder_imports = true
|
|
reorder_modules = true
|
|
tab_spaces = 4
|
|
use_field_init_shorthand = true
|
|
use_try_shorthand = true
|