Vscode-rust: rustfmt.toml not respected?

[Sushisource]

Hello

Loving the plugin. Did notice something I'm fairly sure is a bug:

I've got a rustfmt.toml with

fn_args_density = "Compressed"

In it, and when I run rustfmt on the command line that appears to work, but when running from VS Code it'll use the default "Tall" behavior. This is version 0.2.2 of the plugin.

[nrc]

Does your rustfmt.toml work with the latest rustfmt-nightly? We do explicitly look for a rustfmt.toml, so this should work, you may have hit a bug though.

[Sushisource]

Certainly seems so, running rustup show says I'm on nightly and then cargo fmt produces the correct result while format in VS Code undoes it

[nrc]

the rust version is not linked to the rustfmt version. Try running rustfmt --version, you should see something like nightly-0.2.2

[Sushisource]

Ah, yup, my bad. That was exactly it. I must've somehow had an old version. It also seemed if I had a directory override set to apply it didn't apply to running rustfmt bare, it complained about missing dlls after I updated it. Running it with "rustup run nightly" worked fine though. My original problem doesn't exist though, both ways are consistent. Thanks!

[Sushisource]

Actually, I'm gonna flip-flop. They do seem divergent. This code is preserved by the vscode plugin as-is:

    let mut get_siz = || {
      sizer.ind_sample(&mut rng).abs().max(scaler / 30.0).min(scaler / 2.0) as f32
    };

The long line is > 80 cols.

But this:

>rustup run nightly rustfmt src\dungeongen\rooms.rs
>rustup run nightly rustfmt -V
0.2.2-nightly ( )

Results in:

    let mut get_siz = || {
      sizer
        .ind_sample(&mut rng)
        .abs()
        .max(scaler / 30.0)
        .min(scaler / 2.0) as f32
    };

With this config:

max_width = 80
tab_spaces = 2
fn_args_density = "Compressed"
fn_single_line = true
single_line_if_else_max_width = 70

Actually after typing all that I just put in some random whitespace, and seems it's jut not formatting at all, which I don't think was happening earlier, so I've got no clue now why it's gone wrong. There aren't any errors in the problems tab. Sorry for the awful bug report.

[colemickens]

I'm having this problem.

$ rustfmt --version
0.9.0-nightly ( )

When I run cargo fmt -- --write-mode=overwrite, it respects Cargo.toml and doesn't put annotations next to fields in structs.

When I save in VS Code, it seems to be ignoring the rustfmt.toml. Which version does VS Code use? I would've assumed it's the same one as the nightly toolchain is my default.

[scottjmaddox]

I'm also having this problem. cargo fmt respects rustfmt.toml, but VSCode Format Document does not.

I'm on macOS 10.12.6
VSCode version is 1.17.0
Rust (rls) version is 0.3.1

$ cargo fmt -- --version
0.2.8-nightly ( )

[stiv-yakovenko]

I also have the same problem, rustfmt ignores rustfmt.toml

[dvdplm]

I am seeing the same thing here, vscode does not seem to respect the rustfmt.toml while cargo fmt -- --write-mode=overwrite does.

Version:

$ cargo fmt -- --version
0.6.2 ()

[jonasbb]

@dvdplm You are using the old version of rustfmt. If you want to compare the formatting of rustfmt and rls you need to use the rustfmt-nightly crate.

[dvdplm]

@jonasbb thank you, I missed that. However, even with rustfmt-nightly at the right version the problem with VSCode remains. :/

[norru]

I am seeing a similar problem in Eclipse Rust corrosion plugin. If it helps, in my case It does seem to be caused by rls launching rustfmt from the user's home directory rather than the project root. This seems to be causing rustfmt to attempt loading $HOME/.rustfmt.toml rather than /path/to/cargo_project/.rustfmt.toml

[Xanewok]

This should be fixed on VSCode side of things, since we always spawn RLS in the workspace side of things, however RLS itself might need to take the rootUri into account instead of the cwd.

Opened https://github.com/rust-lang/rls/issues/1418 to track.

[timvermeulen]

I still seem to be having this issue (I'm using rustfmt-nightly).

[supernomad]

for what its worth I am seeing this still as well I have tried a rustfmt.toml and a .rustfmt.toml neither seem to get picked up by rls when formating on save is enabled in vscode. When I run cargo +nightly fmt -- --emit=files everything works as expected :disappointed:.

$ rustfmt --version
rustfmt 1.4.9-nightly (33e3667 2019-10-07)

$ rls --version
rls 1.38.0 (7b0a20b 2019-08-11)

rls-vscode: 0.7.0

I am not entirely sure what exactly is happening but would love some guidance on how to fix this particular issue.

[tobx]

My current workaround is to edit settings.json:

"rust.rustfmt_path": "~/.cargo/bin/rustfmt"

It might help to replace ~ with ${env.HOME} if there are any issues. On macOS this works.

[edwardloveall]

FWIW, I spend a day working with this problem and have learned some things:

• A vscode extension thinks the path of child_process.execSync is /
• If you run rustfmt from / it does not pick up the rustfmt.toml

For example:

cd /full/path/to/rust
cat /full/path/to/rust/file.rs | rustfmt

# formatted rust that uses rustfmt.toml

cd /
cat /full/path/to/rust/file.rs | rustfmt

# default formatted rust

I've been playing around with this extension and adding the project directory to child_process.execSync fixes this for me:

function getFormattedString(doc: vscode.TextDocument): string {
+   const documentUri = vscode.Uri.parse(doc.fileName);
+   const workspaceDir = vscode.workspace.getWorkspaceFolder(documentUri);
    return child_process.execSync("rustfmt", {
        encoding: 'utf-8',
        input: doc.getText(),
+       cwd: workspaceDir.uri.fsPath,
    }).toString();
}

I realize this is for an entirely different project but this is what comes up in search result so perhaps it will help someone.

[chamons]

I am still seeing this in 3/21.