[unstable option] version #3383

Activity

1. scampi

   added

   unstable-optionTracking issue of an unstable optionTracking issue of an unstable option

   on Feb 13, 2019
2. scampi commented on Feb 21, 2019

   

   scampi

   on Feb 21, 2019

   ContributorAuthor

   More actions

   original issue: #2877
3. topecongiro commented on Jun 23, 2019

   

   topecongiro

   on Jun 23, 2019

   Contributor

   More actions

   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]

   👍React with 👍3Reacted by Crystal Durham, Martijn Gribnau and Tukusej’s Sirs
4. yvt

   added a commit that references this issue on Feb 7, 2020

   style: upgrade the rustfmt rule version to `Version::Two`

   ...

   979a35a
5. topecongiro

   added this to the 2.0.0 milestone on Jun 6, 2020
6. topecongiro

   closed this as completedin #4235on Jun 6, 2020
7. karyon commented on Nov 14, 2021

   

   karyon

   on Nov 14, 2021

   Contributor

   More actions

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

   reopened this on Nov 14, 2021
9. tukusejssirs commented on Jul 26, 2022

   

   tukusejssirs

   on Jul 26, 2022

   More actions

   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.
10. mickvangelderen commented on Apr 21, 2023

    

    mickvangelderen

    on Apr 21, 2023

    More actions

    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.
11. mickvangelderen commented on Apr 21, 2023

    

    mickvangelderen

    on Apr 21, 2023

    Last edited by mickvangelderen

    More actions

    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)
12. karyon commented on Apr 22, 2023

    

    karyon

    on Apr 22, 2023

    Contributor

    More actions

    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!

    👍React with 👍2Reacted by Mick van Gelderen and Yacin Tmimi
13. tgross35 commented on Jul 25, 2023

    

    tgross35

    on Jul 25, 2023

    Member

    More actions

    This will likely be superceded in some way by rustfmt editions, correct?
14. calebcartwright commented on Jul 25, 2023

    

    calebcartwright

    on Jul 25, 2023

    Member

    More actions

    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

    👍React with 👍2Reacted by Trevor Gross and Alex
15. calebcartwright

    closed this as not plannedon Jul 25, 2023