Stabilise `--skip-children`

[Timmmm]

It's unlikely that Rustfmt 2.0 will be released for a while, if ever, so it would be nice if --skip-children could be stabilised so we can use stable Rustfmt with arc lint (a Phabricator tool). It's been around for "a long time".

[calebcartwright]

I'd forgotten this still hadn't been stabilized 👀 It's been around for north of four years so it would certainly be a candidate for stabilization, however, I think this may turn out to be a good thing.

Changing this behavior (non-recursive by default, if you are running rustfmt directly then include the new --recursive flag which cargo fmt will do on your behalf) is something that I wanted to try to push through anyway, and it'll be easier to do so since this is not a stable option.

I'll see if the dev tools team is onboard with this, and hopefully will be able to make the main change soon. If not, will certainly consider stabilizing this option.

[Timmmm]

Did you manage to ask the dev tools team about it?

[calebcartwright]

Updates will be posted as and when they are available, and the absence of posted updates means that there are no updates. Stay tuned

[Timmmm]

Can you actually change the default behaviour to be non-recursive? Wouldn't that be a breaking change?

[calebcartwright]

I feel like there's a lot of subtext behind your question which I'll largely avoid except to say that I have no intention of stabilizing this option unless something dramatic changes (and yes I realize that's a change in position from several months ago, but that's due to this being part of a broader strategy that's evolved since then)

Can you actually change the default behaviour to be non-recursive? Wouldn't that be a breaking change?

This is of course part of the calculus and has always been part of the considerations and discussions. It's a grey area, but no not necessarily breaking. This can be done in a way that's transparent with no behavioral change for cargo fmt, causes no errors for the rarer cases of those running rustfmt directly, and fixes a long standing bug in editor formatting behavior.

[Timmmm]

I feel like there's a lot of subtext behind your question

I'm not sure what you mean. I was just wondering if you really were considering making a breaking change to the behaviour, since this project seems to care quite a lot about stability (e.g. requiring nightly for --unstable-features). It definitely is a breaking change, but I'm not a zero-breaking-changes extremist so I'm all for it (maybe selfishly since it doesn't break anything of mine!).

[Timmmm]

I've been looking at this again recently, and found some more relevant links:

• Add feature to only changes that were already modified (git) #1324
• can cargo fmt or rustfmt format a list of files please? #4485
• Allow cargo-fmt to handle formatting individual files. #5071 (this looks like the one to follow)

Also I found:

• You actually can format a single file without using nightly: you can pipe it into rustfmt's stdin (wish I'd realised that 4 years ago!)
• If you don't use cargo fmt you have to set the edition manually (makes sense).

[alshdavid]

I've created a wrapper around rustfmt and cargo fmt that allows formatting one/many files (non recursively) and also enables nightly formatting features without installing nightly Rust.

https://github.com/alshdavid/cargo-xfmt

cargo install cargo-xfmt

# format all files
cargo xfmt

# format one or many files (non recursive)
cargo xfmt --file ./src/main.rs --file ./src/foo.rs

# Or from stdin
cat ./src/main.rs | cargo xfmt > ./src/main_formatted.rs

And in vscode

{
  "rust-analyzer.rustfmt.overrideCommand": [
    "cargo", "xfmt",
  ]
}