Revert "defer changes for zero argument functions until style_edition=2027"

[ytmimi]

This effectively reverts commit a7e0c15d264fcc655c3b249d924e0852009d93fc from PR https://github.com/rust-lang/rustfmt/pull/6362

This change made it into the 2024 style-edition so we can't defer it to 2027.

r? @calebcartwright

[calebcartwright]

I think this is the one my brain glitched on last month. To clarify, are you saying rustfmt (the released, rustfmt available on the toolchains) currently is incorrectly formatting these according to a style change that was punted to 2027 edition?

If so I want to make sure we account for that on the style side is well

[ytmimi]

@calebcartwright based on your comment https://github.com/rust-lang/rustfmt/issues/5577#issuecomment-2094503553 I know there was interest from t-style to not mess with how we format zero argument functions. Unfortunately the zero argument function changes described in https://github.com/rust-lang/rustfmt/issues/5577#issuecomment-1345037570 were included in Rust 2024.

Here's the rough timeline

• 2024-09-20 Subtree Sync for https://github.com/rust-lang/rust/pull/130593
• 2024-10-21 Merge Defer changes for zero argument functions until style_edition=2027
• 2025-02-20 Edition 2024 gets released

Because we haven't done a sync since 2024-09-20 we need to revert the zero argument function changes we made in #6362 before we can sync back with r-l/rustfmt.

[calebcartwright]

I appreciate the timeline. I believe this was all happening when I was out sick and without a computer for an extended period of time.

For future reference, in cases like that where expediency is required we should absolutely make the changes in-tree in r-l/rust and not couple ourselves to the sync, just like we do for critical bug fixes.

Our sync process is too slow and clunky (details here) to be able to always make changes in r-l/rustfmt

Need to make style team aware and probably update the style guide for 2024 to ensure it reflects the actual behavior in that edition