-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update Rustfmt (add let-else support) #113225
Conversation
The function properly handles recovering comments before and after the `else` keyword, and properly handles how to write the else when users configure `control_brace_style`.
This will make it easier to format the divergent blocks of `let-else` statements since it'll be easier to prevent the block from being formatted on a single line if the preconditions aren't met.
`rewrite_let_else_block` gives us more control over allowing the `else` block to be formatted on a single line than `<ast::Block as Rewrite>::rewrite`.
These test cases try to cover various edge cases. For example, comments around the else keyword and long, unbreakable, single-line initializer expressions, and long patterns.
This helps to prevent max width errors.
This allows users to configure the maximum length of a single line `let-else` statements. `let-else` statements that otherwise meet the requirements to be formatted on a single line will have their divergent `else` block formatted over multiple lines if they exceed this length. **Note**: `single_line_let_else_max_widt` will be introduced as a stable configuration option.
By reversing the logic I felt that the code became a clearer. Also, added a comment to make it clear that we need to take the trailing semicolon for the `let-else` statement into account.
This rule wasn't explicity stated in the style guide so it was missed, but luckily we caught it during testing.
(rustbot has picked a reviewer for you, use r? to override) |
These commits modify the If this was unintentional then you should revert the changes before this PR is merged. Some changes occurred in src/tools/rustfmt cc @rust-lang/rustfmt |
r? @ghost |
Failed to set assignee to
|
r? calebcartwright |
@bors r+ p=2 rollup=never We just about always do a p 1-5 for subtree syncs, and going higher in this case to increase the chances of getting this out with the next nightly |
☀️ Test successful - checks-actions |
Finished benchmarking commit (6162f6f): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 662.874s -> 661.654s (-0.18%) |
Support for `let…else` formatting was just merged to nightly (rust-lang/rust#113225). Rerun `cargo fmt` with Rust nightly 2023-07-02 to pick this up. Followup to #939. Signed-off-by: Anders Kaseorg <andersk@mit.edu>
Adds let-else formatting support
Bit more detail in: https://github.com/rust-lang/rustfmt/blob/master/CHANGELOG.md#160-2023-07-02
Accompanying blog post: rust-lang/blog.rust-lang.org#1117
I know we're getting close to tool week, however, there's been extensive discussion and testing of the changes in this between both t-style and t-rustfmt. Our confidence level is extremely high, and even if it's only on nightly for a few days, I'd still much prefer that and being able to get this out with 1.72 vs having to push to 1.73
Closes rust-lang/rustfmt#4914
cc @rust-lang/style for awareness