implement 2024 expression overflowing #6260

calebcartwright · 2024-08-02T04:27:42Z

This PR does two things:

builds on prior work to allow rustfmt to support different default values for configuration options based on the style edition
implements the 2024 style edition work for overflow behavior on delimited expressions in "combinable" positions (Tracking Issue for Rust 2024: rustfmt enable overflow_delimited_expr rust#123751)

These two items were combined in the same PR because it's much, much easier to test and demonstrate the former by the latter, and the latter cannot be done without the former.

The vast majority of the diff consists of test snippets taken from existing tests, so shouldn't be as difficult a review as one might infer from the diff numbers. Commits structured in a way that's hopefully logical and conducive to commit-by-commit review

There's a few things we can probably bikeshed on (names, inclusion of helper functions to minimize number of unnecessary callsite changes, etc.) that I'll add inline comments on later

r? @ytmimi

ytmimi

I went through each commit one by one. They were organized very logically and that made the PR much easier to review. I've very happy to move forward with the PR without any bikesheding!

calebcartwright · 2024-08-16T01:28:29Z

From a design perspective, there were a few ways I could see that we could potentially utilize for having configuration defaults that could vary by style edition (ordered only for reference, not in any preference/priority):

"on_set" event inline overrides
load 2015 & then merge with detected style edition version defaults
load 2015 & reload with detected style edition
load based on inputted/calculated style edition

All of these options have drawbacks, but I opted for option (d) as I think it's the lesser of the evils in the grand scheme of things.

The issue with (a) is that while it works and would likely be maintainable for the 2024 edition, it is a tad hacky and overtime would likely grow to be rather unwieldy.

The issue with (b) is that there are various configuration options who have cascading effects on other options (e.g. use_small_heuristics) so attempting to merge two config structs while maintaining the user specified values starts to get much more complex than one would first anticipate (e.g. imagine edition 2027 needs to change the default value of array_width but not the value of use_small_heuristics). Trying to merge in a scenario where the user has specified a non-default value for use_small_heuristics and/or max_width (or any other combination of cascading options) is technically possible, but I couldn't see a straightforward way of doing it without breaking internal encapsulation and duplicating responsibilities within the codebase

The issue with (c) is that it's inherently inefficient; going through the entire configuration loading process just to determine the derived style_edition value only to then do the same thing all over again with the now known style edition value

The downside to the proposed path here, option (d), is that I feel it does bleed some CLI specifics a bit into the configuration loading process. The CliOptions struct is actually already defined within the config module so there's been some level of familiarity there from the outset, but I did have to extend this trait so that in addition to having a getter-like function for the inline config, there's now similar functions for grabbing the style edition, edition, and (temporarily) the version value. I don't love it, but as I said at the outset, lesser of the evils

calebcartwright · 2024-08-16T01:29:04Z

rustfmt.toml

@@ -1,3 +1,4 @@
 error_on_line_overflow = true
 error_on_unformatted = true
 style_edition = "2024"
+overflow_delimited_expr = false


I added this to reduce churn, as the 2024 default (true) will require some updates to the formatting of the rustfmt codebase itself

calebcartwright · 2024-08-16T01:30:55Z

src/config/config_type.rs

@@ -210,7 +208,7 @@ macro_rules! create_config {
            )+

            #[allow(unreachable_pub)]
-            pub fn default_with_style_edition(style_edition: StyleEdition) -> Config {
+            pub(super) fn default_with_style_edition(style_edition: StyleEdition) -> Config {


I may have just been caught up in the difficulty of naming things, but I did feel odd having this function as well as default_for_possible_style_edition. While the function names imply a lot of overlap, I do feel they are doing very different things.

This function is very much instantiating a config with the provided style edition, whereas default_for_possible_style_edition is more of a "figure out what style edition we should be using, and then give me the default config for that style edition"

Might be worth adding doc comments to explain what each function's purpose is within the codebase.

calebcartwright · 2024-08-16T01:32:01Z

src/config/mod.rs

+    pub(super) fn from_toml(toml: &str, dir: &Path) -> Result<Config, String> {
+        Self::from_toml_for_style_edition(toml, dir, None, None, None)
+    }


I debated with myself whether this was necessary, but I opted to put it in for now so as to reduce the amount of diff in the PR. I think we can consider removing it later and just updating the various call sites (which were all in tests if I recall correctly)

Yeah, I didn't see any issue with from_toml, and if it's only used in test code then we don't have to make any changes right now

calebcartwright · 2024-08-16T01:33:19Z

src/config/mod.rs

            Ok(parsed_config) => {
                if !err.is_empty() {
                    eprint!("{err}");
                }
-                Ok(Config::default().fill_from_parsed_config(parsed_config, dir))
+                Ok(parsed_config.to_parsed_config(style_edition, edition, version, dir))


I also didn't love the parsed_config.to_parsed_config piece here, as the idents make for a confusing combination. I think this could be avoided with a simple rename but as always naming things is hard 🤷

Yeah, I saw that and thought the wording was a bit confusing, but nothing too bad to stop us from moving forward with these changes.

ytmimi · 2024-08-16T01:38:20Z

From a design perspective, there were a few ways I could see that we could potentially utilize for having configuration defaults that could vary by style edition (ordered only for reference, not in any preference/priority):

"on_set" event inline overrides

load 2015 & then merge with detected style edition version defaults

load 2015 & reload with detected style edition

load based on inputted/calculated style edition

All of these options have drawbacks, but I opted for option (d) as I think it's the lesser of the evils in the grand scheme of things.

The issue with (a) is that while it works and would likely be maintainable for the 2024 edition, it is a tad hacky and overtime would likely grow to be rather unwieldy.

The issue with (b) is that there are various configuration options who have cascading effects on other options (e.g. use_small_heuristics) so attempting to merge two config structs while maintaining the user specified values starts to get much more complex than one would first anticipate (e.g. imagine edition 2027 needs to change the default value of array_width but not the value of use_small_heuristics). Trying to merge in a scenario where the user has specified a non-default value for use_small_heuristics and/or max_width (or any other combination of cascading options) is technically possible, but I couldn't see a straightforward way of doing it without breaking internal encapsulation and duplicating responsibilities within the codebase

The issue with (c) is that it's inherently inefficient; going through the entire configuration loading process just to determine the derived style_edition value only to then do the same thing all over again with the now known style edition value

The downside to the proposed path here, option (d), is that I feel it does bleed some CLI specifics a bit into the configuration loading process. The CliOptions struct is actually already defined within the config module so there's been some level of familiarity there from the outset, but I did have to extend this trait so that in addition to having a getter-like function for the inline config, there's now similar functions for grabbing the style edition, edition, and (temporarily) the version value. I don't love it, but as I said at the outset, lesser of the evils

I really appreciate you taking the time to outline your thoughts and all the tradeoffs that we could have made here. (d) feels like the best option in my opinion, and it's the one that I likely would have come up with if I was working to implement this. I'm sure we can rework this in the future if it becomes an issue.

Bump stage0 to beta-2024-09-22 and rustfmt to nightly-2024-09-22 I'm doing this to apply the changes to version sorting (rust-lang/rustfmt#6284) that have occurred since rustfmt last upgraded (and a few other miscellaneous changes, like changes to expression overflowing: rust-lang/rustfmt#6260). Eagerly updating rustfmt and formatting-the-world will ideally move some of the pressure off of the beta bump which will happen at the beginning of the next release cycle. You can verify this is correct by checking out the changes, reverting the last commit, reapplying them, and diffing the changes: ``` git fetch [email protected]:compiler-errors/rust.git bump git checkout -b bump FETCH_HEAD git reset --hard HEAD~5 ./x.py fmt --all git diff FETCH_HEAD # ignore the changes to stage0, and rustfmt.toml, # and test file changes in rustdoc-js-std, run-make. ``` Or just take my word for it? Up to the reviewer. r? release

rustbot added the pr-not-reviewed label Aug 2, 2024

calebcartwright force-pushed the 2024-overflow-delim-expr branch from 7869b0c to 65bd027 Compare August 14, 2024 21:43

calebcartwright marked this pull request as ready for review August 14, 2024 21:43

calebcartwright mentioned this pull request Aug 14, 2024

Tracking Issue for Rust 2024: rustfmt enable overflow_delimited_expr rust-lang/rust#123751

Open

4 tasks

calebcartwright added p-high a-2024-edition Style Edition 2024 labels Aug 14, 2024

calebcartwright requested a review from ytmimi August 14, 2024 21:56

ytmimi approved these changes Aug 16, 2024

View reviewed changes

calebcartwright commented Aug 16, 2024

View reviewed changes

calebcartwright added 5 commits August 27, 2024 20:02

refactor: use style edition when loading from partial config

c84b893

refactor: include edition & style edition in CliOptions

5a168ff

feat: support style edition differing defaults in config loading

8f728b0

feat: implement 2024 Style Edition for expr overflows

b7b3835

refactor: improve mapping of legacy 'version' to 'style_edition'

5a403eb

calebcartwright force-pushed the 2024-overflow-delim-expr branch from 65bd027 to 5a403eb Compare August 28, 2024 01:02

calebcartwright removed the pr-not-reviewed label Aug 28, 2024

calebcartwright merged commit 46cb7d3 into rust-lang:master Aug 28, 2024
26 checks passed

calebcartwright deleted the 2024-overflow-delim-expr branch August 28, 2024 01:49

ytmimi added the release-notes Needs an associated changelog entry label Sep 3, 2024

ytmimi removed the release-notes Needs an associated changelog entry label Sep 20, 2024

compiler-errors mentioned this pull request Sep 22, 2024

Bump stage0 to beta-2024-09-22 and rustfmt to nightly-2024-09-22 rust-lang/rust#130724

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

implement 2024 expression overflowing #6260

implement 2024 expression overflowing #6260

calebcartwright commented Aug 2, 2024 •

edited

Loading

ytmimi left a comment

calebcartwright commented Aug 16, 2024

calebcartwright Aug 16, 2024

calebcartwright Aug 16, 2024

ytmimi Aug 16, 2024

calebcartwright Aug 16, 2024

ytmimi Aug 16, 2024

calebcartwright Aug 16, 2024

ytmimi Aug 16, 2024 •

edited

Loading

ytmimi commented Aug 16, 2024

implement 2024 expression overflowing #6260

implement 2024 expression overflowing #6260

Conversation

calebcartwright commented Aug 2, 2024 • edited Loading

ytmimi left a comment

Choose a reason for hiding this comment

calebcartwright commented Aug 16, 2024

calebcartwright Aug 16, 2024

Choose a reason for hiding this comment

calebcartwright Aug 16, 2024

Choose a reason for hiding this comment

ytmimi Aug 16, 2024

Choose a reason for hiding this comment

calebcartwright Aug 16, 2024

Choose a reason for hiding this comment

ytmimi Aug 16, 2024

Choose a reason for hiding this comment

calebcartwright Aug 16, 2024

Choose a reason for hiding this comment

ytmimi Aug 16, 2024 • edited Loading

Choose a reason for hiding this comment

ytmimi commented Aug 16, 2024

calebcartwright commented Aug 2, 2024 •

edited

Loading

ytmimi Aug 16, 2024 •

edited

Loading