[unstable option] version

[scampi]

Tracking issue for version

[scampi]

original issue: #2877

[topecongiro]

I would like to rename this option and/or change it so that it won't take a major version number as its value.

Currently (the version 1.x) rustfmt supports version = "One" or version = "Two". If we release 2.0, then version = "One" will be deprecated and version = "Three" will be supported. Now the problem: every user whose rustfmt.toml contains version needs to update their file to keep the behavior of rustfmt as what they expecet.

I will list some candidates below which I have in my mind. Suggestions for better wording are welcome!

• version = ["stable"|"nightly"]
• version = ["current"|"latest"]
• ues_latest_format_style = [true|false]

[karyon]

This will need to be re-decided for 1.x

[tukusejssirs]

I will list some candidates below which I have in my mind. Suggestions for better wording are welcome!

• version = ["stable"|"nightly"]
• version = ["current"|"latest"]
• ues_latest_format_style = [true|false]

I suggest to use the following values:

• nightly: latest nightly release;
• current: current/latest major stable release;
• previous: previous (last but one) major stable release:
  • this one might be removed, however, you might want to add a way to add this option, as currently we can use the previous major release;
• ${major}: match major version number:
  • value could be required to be a string if you want to use a single data type for version option;
  • for example 1, 2.

In order to remove the maintaince burden, support of nightly, current and previous might be supported only.

[mickvangelderen]

I would like to rename this option and/or change it so that it won't take a major version number as its value.

As I understand it the motivation for having a version field is stability with respect to the formatting output. If my understanding is correct, then relative values such as nightly and current defeat the point.

Now the problem: every user whose rustfmt.toml contains version needs to update their file to keep the behavior of rustfmt as what they expecet.

The following RFC intends to solve the question of how rustfmt can improve the (default) formatting output rust-lang/rfcs#3338 by allowing the default formatting output to change between editions. The idea being that when you change editions, you might already want to go through the source code of the crate that is changing editions to make use of any new language features that have been introduced or eliminate the use of deprecated features. That might also be a good time to reformat the code.

[mickvangelderen]

I am curious why this issue was reopneend. Is it possible to provide the motivation for re-opening this issue @karyon? (also, I was surprised to see that your master's thesis also made use of Osslon's clustered shading paper. I did not find a way to contact you so I'm writing here)

[karyon]

The PR was merged to the abandoned 2.x branch (which was master for a while). In the current master, the version config still exists: https://github.com/rust-lang/rustfmt/blob/master/Configurations.md#version.

Heh, funny that you found that. I put my email address into my profile, feel free to shoot me a message!

[tgross35]

This will likely be superceded in some way by rustfmt editions, correct?

[calebcartwright]

This will likely be superceded in some way by rustfmt editions, correct?

Correct, this is going to be replaced by a new style_edition option as per RFC 3338. version=Two will be the equivalent to style_edition=2024, version=One will be the equivalent to style_edition=(2015|2018|2021), and version will be soft-deprecated for some period of time with a warning and automatic mapping to the equivalent style_edition value.

---

If anyone finds any issues with the existing version option then feel free to report here until we get style_edition in place, but going to close this since we won't be proceeding with stabilizing version