Repository navigation
Tracking issue for RFC 2437, "Rustfmt stability" #54504
Description
This is a tracking issue for the RFC "Rustfmt stability" (rust-lang/rfcs#2437).
Steps:
- Implement the RFC (cc @nrc)
- Adjust documentation (see instructions on forge)
- Stabilization PR (see instructions on forge)
Unresolved questions:
- Do we want to specify the version in Cargo instead of/as well as in
rustfmt.toml?
Activity
scampi commentedon Jul 20, 2019
This issue should be closed, or is there something left to do ?
topecongiro commentedon Sep 5, 2019
This has been a serious pain point of maintaining rustfmt. I am looking for a way to pursue the stability guarantee without messing around the codebase of rustfmt.
Could we relax this stability guarantee only to rustfmt-stable?
dtolnay commentedon Jun 11, 2020
Clarification on the RFC (@topecongiro or @nrc): what is meant by "formatting won't change without an explicit upgrade"? If
rustfmt2.4andrustfmt2.5are two versions of rustfmt without an explicit upgrade in between, does it mean one of these?:input | rustfmt2.4==input | rustfmt2.5input | rustfmt2.4==input | rustfmt2.4 | rustfmt2.5So far I tended to assume option 2 because it makes more sense to me but checking the RFC I don't think this is clear. If anything the wording "formatting according to the rules of previous versions" implies option 1, but the motivation is all described in terms of option 2 (ability to enforce formatting in CI; preventing frequent reformats on toolchain upgrades).
The difference would be apparent if e.g. an option whose default is "do something" changes its default to "do nothing", such as
merge_derives = true->merge_derives = false.nrc commentedon Jun 11, 2020
I had not thought about it with this framing. I think we meant option 2, my framing would be:
which I think is a little weaker if there exists an input that is not stable under repeated formatting (which there should not be, but there sometimes is).
Caveat: my reasoning may be out of date if the rustfmt maintainers have changed their thinking since I was involved.
mickvangelderen commentedon Apr 12, 2023
It has been close to 3 years without visible activity on this RFC. I suppose that means that the rustfmt authors have been doing a good job when it comes to stability! Also from personal experience I can say that it has been a pleasure to use and has not cause any undesirable churn.
I am a bit lost as to what the exact purpose is of this RFC. Is it just to define what stability means for rustfmt? Does it suggest adding a version field somewhere to allow easily pinning a specific rustfmt version? Is that something we should want on top of pinning a compiler version? Who does this serve? Are we trying to enable rustfmt authors to make changes to the default formatting output or are we trying to give control to rustfmt consumers over when they would like to reformat their code?
Perhaps related, rust-lang/rfcs#3338 intends to enable the evolution of the default formatting output over time and so achieving that should maybe not be considered a goal for this RFC (if it ever was, perhaps subconciously).
calebcartwright commentedon Apr 13, 2023
I'm going to close this as it's out of date, not being worked against, and largely achieved the original goal anyway.
Circumstances have changed significantly in the nearly 5 years since this was opened, and there's a need to refresh the guarantee both to reflect those various changes (very small ones, e.g. rustfmt is no longer a submodule in tree, and large ones, e.g. RFC #338 - Style Edition), and with the benefit of hindsight, to provide additional clarity and context on some key questions and topics (e.g. #54504 (comment))