Tracking issue: rustfmt 2.0

[topecongiro]

Also, see Milestone for 2.0.

Blocking issues

• Separate rustfmt-lib (Split out a rustfmt-core crate #1583)
• Remove version gates (Remove version gates from rustfmt codebase #3886)
• Update the default edition to 2018 (Update default edition to 2018 #3517)
• Use different versions of rustfmt-lib crates to enforce stability guarantee (Use different versions of lib crate to enforce stability guarantee #3841)

Help wanted

• Add --check command-line flag to cargo-fmt (Add --check command-line flag to cargo-fmt #3888)
• Deprecate --backup command-line flag
• Deprecate --skip-children command-line flag and skip_children configuration option ([unstable option] skip_children #3389 and deprecate skip_children option #3893)
• Add --recursive command-line flag

Non-blocking issues

Any issues concerning formatting bugs will be non-blocking.

[calebcartwright]

I didn't find any related issues on this, but I'd suggest considering an update/refresh of some sections in the README as part of 2.0

As an example, the Limitations section starts with several mentions of approaching 1.0:

Rustfmt tries to work on as much Rust code as possible, sometimes, the code doesn't even need to compile! As we approach a 1.0 release we are also looking to limit areas of instability; in particular, post-1.0, the formatting of most code should not change as Rustfmt improves. However, there are some things that Rustfmt can't do or can't do well (and thus where formatting might change significantly, even post-1.0). We would like to reduce the list of limitations over time.

[calebcartwright]

Also, I'm still working on chains ATM, but I'd be happy to work on adding the --recursive flag and/or deprecating the --backup flag if those are still up for grabs?

[topecongiro]

I didn't find any related issues on this, but I'd suggest considering an update/refresh of some sections in the README as part of 2.0

Will do. Thanks!

Also, I'm still working on chains ATM, but I'd be happy to work on adding the --recursive flag and/or deprecating the --backup flag if those are still up for grabs?

Yes, you are more than welcome to work on those :)

[calebcartwright]

Just to clarify, the goal is just to deprecate the --backup flag, not to entirely remove the flag/FilesWithBackupEmitter/etc., correct?

[scampi]

@calebcartwright I would think so, just a deprecation for --backup

[calebcartwright]

Thanks @scampi! Seems straightforward enough for --backup, though in the case of --skip-children, won't there be the potential for conflict once --recursive is added?

For example, if a user still has skip_children in a rustfmt.toml file, and then rustfmt is invoked with the --recursive flag (most likely scenario being via cargo fmt ... since that will include --recursive by default), what's the expected outcome?

Should rustfmt exit with an error? Or emit a warning and let one of the conflicting options take precedence?

[scampi]

Since rustfmt is invoked with the --recursive flag, it should have higher priority over the skip_children option in rustfmt.toml.
I think that logic should be applied regardless of the deprecation here, i.e., CLI flags have precedence over rustfmt.toml. What do you think ?

[calebcartwright]

I'd vote for rustfmt to exit with an error. From my perspective, recursive and skip_children are separate, mutually exclusive config options and "failing loudly" in the presence of both seems logical.

It feels like a similar situation as when a user specifies both --check and --emit flags; you can't have both so rustfmt exits with an error

[scampi]

Indeed makes sense @calebcartwright , error it is then!

[topecongiro]

Closing this as we are using the GitHub's milestone to track issues for 2.0.

[Keavon]

What's the status of rustfmt 2.0's release? The milestone tracking issue only shows one incomplete issue, but it hasn't had activity in months. The rustfmt-2.0 branch in the repo also has not had a commit since 2019.