Format heterogeneous try blocks by ia0 · Pull Request #152293 · rust-lang/rust

ia0 · 2026-02-07T14:56:34Z

The tracking issue for try_blocks_heterogeneous is #149488.

This follows the formatting of homogeneous try blocks (feature try_blocks) by considering try bikeshed <type> to be the equivalent of try (in particular a single "token").

An alternative would be to permit breaking between bikeshed and <type>, but given that those 2 elements are an explicitly temporary part of the syntax, it doesn't seem worth it. There also doesn't seem to be any existing precedent breaking between a keyword and a type. It also doesn't seem to be useful in practice, given that the type itself doesn't break (which is how it works for the return type of closures) and has more chances to dominate the length in case a break is necessary.

Happy to adapt anything in case this formatting is not optimal.

The test is also copied from homogeneous try blocks with 2 additional test cases to demonstrate the behavior with long types.

See #t-lang > try blocks @ 💬 for context.

rustbot · 2026-02-07T14:56:38Z

Some changes occurred in src/tools/rustfmt

cc @rust-lang/rustfmt

rustbot · 2026-02-07T14:56:40Z

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

Fallback group: @Mark-Simulacrum, @jieyouxu
@Mark-Simulacrum, @jieyouxu expanded to Mark-Simulacrum, jieyouxu
Random selection from Mark-Simulacrum, jieyouxu

ytmimi · 2026-02-07T19:33:28Z

r? @ytmimi

ytmimi · 2026-02-07T19:35:39Z

src/tools/rustfmt/src/expr.rs

-        // FIXME: heterogeneous try blocks, which include a type so are harder to format
-        ast::ExprKind::TryBlock(_, Some(_)) => Err(RewriteError::Unknown),
+        ast::ExprKind::TryBlock(ref block, Some(ref ty)) => {
+            let keyword = "try bikeshed ";


Is there going to be an issue with try /* comment */ bikeshed?

Not more than with try_blocks apparently. It simply won't format. See the test case in catch.rs:

let x = try /* Invisible comment */ { foo()? };

If you do:

let x = try /* Invisible comment */ { foo()? };

It won't format. I've added tests similar to the one of catch.rs.

ytmimi · 2026-02-07T19:36:37Z

src/tools/rustfmt/tests/source/try_blocks_heterogeneous.rs

Let's add #![feature(try_blocks_heterogeneous)] to these tests so that it's easier to tell what experimental feature they're for.

I've also fixed try_block.rs.

Thanks I appreciate that 🙏🏼

ytmimi · 2026-02-07T19:39:00Z

src/tools/rustfmt/src/expr.rs

+                .and_then(|shape| shape.sub_width(2))
+                .max_width_error(shape.width, expr.span)?;
+            let ty_str = ty.rewrite_result(context, ty_shape)?;
+            let prefix = format!("{keyword}{ty_str} ");


Similarly, is there going to be an issue with try bikeshed /* comment */ {ty_str}?

Do we need to handle cases where the type can't fit on the current line and needs to wraps to the next line? Something like:

try bikeshed {ty_str} { }

Good question. I gave my opinion in the PR description. I don't think this is needed given "bikeshed" is temporary so whatever we choose might not be transposable to the final syntax. But I'm happy to do it if we believe it's useful.

This is still experimental so I think it's fine for now. T-style may want to write up some rules for this before stabilization though.

Sorry, I thought I have linked it but apparently didn't. I also wrote a PR from that based on Zulip discussion: #152311.

ytmimi · 2026-02-10T03:43:45Z

#![feature(try_blocks_heterogeneous)] is still experimental but the formatting implementation looks good overall. We'll probably want to add better support for comments in the future and also figure out what we should do if we need to wrap the type to the next line.

@bors r+ rollup

rust-bors · 2026-02-10T03:43:47Z

📌 Commit d5c6866 has been approved by ytmimi

It is now in the queue for this repository.

…mimi Format heterogeneous try blocks The tracking issue for `try_blocks_heterogeneous` is rust-lang#149488. This follows the formatting of homogeneous try blocks (feature `try_blocks`) by considering `try bikeshed <type>` to be the equivalent of `try` (in particular a single "token"). An alternative would be to permit breaking between `bikeshed` and `<type>`, but given that those 2 elements are an explicitly temporary part of the syntax, it doesn't seem worth it. There also doesn't seem to be any existing precedent breaking between a keyword and a type. It also doesn't seem to be useful in practice, given that the type itself doesn't break (which is how it works for the return type of closures) and has more chances to dominate the length in case a break is necessary. Happy to adapt anything in case this formatting is not optimal. The test is also copied from homogeneous try blocks with 2 additional test cases to demonstrate the behavior with long types. See [#t-lang > try blocks @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/try.20blocks/near/572387493) for context.

Rollup of 7 pull requests Successful merges: - #151152 (Add FCW for derive helper attributes that will conflict with built-in attributes) - #151954 (Add help message suggesting explicit reference cast for From/TryFrom) - #152148 (Move `impl Interner for TyCtxt` to its own submodule) - #152226 (Modernize diagnostic for indeterminate trait object lifetime bounds) - #150688 (typeck: Make it clearer that `check_pat_lit` only handles literal patterns) - #152293 (Format heterogeneous try blocks) - #152396 (Uplift `Predicate::allow_normalization` to `rustc_type_ir`)

…mimi Format heterogeneous try blocks The tracking issue for `try_blocks_heterogeneous` is rust-lang#149488. This follows the formatting of homogeneous try blocks (feature `try_blocks`) by considering `try bikeshed <type>` to be the equivalent of `try` (in particular a single "token"). An alternative would be to permit breaking between `bikeshed` and `<type>`, but given that those 2 elements are an explicitly temporary part of the syntax, it doesn't seem worth it. There also doesn't seem to be any existing precedent breaking between a keyword and a type. It also doesn't seem to be useful in practice, given that the type itself doesn't break (which is how it works for the return type of closures) and has more chances to dominate the length in case a break is necessary. Happy to adapt anything in case this formatting is not optimal. The test is also copied from homogeneous try blocks with 2 additional test cases to demonstrate the behavior with long types. See [#t-lang > try blocks @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/try.20blocks/near/572387493) for context.

…uwer Rollup of 11 pull requests Successful merges: - #152364 (Port a lot of attributes to the new parser) - #151954 (Add help message suggesting explicit reference cast for From/TryFrom) - #152148 (Move `impl Interner for TyCtxt` to its own submodule) - #152226 (Modernize diagnostic for indeterminate trait object lifetime bounds) - #152351 (Remove `SubdiagMessage` in favour of the identical `DiagMessage`) - #152417 (Move the needs-drop check for `arena_cache` queries out of macro code) - #150688 (typeck: Make it clearer that `check_pat_lit` only handles literal patterns) - #152293 (Format heterogeneous try blocks) - #152355 (Update documentation of rustc_macros) - #152396 (Uplift `Predicate::allow_normalization` to `rustc_type_ir`) - #152425 (Port #![test_runner] to the attribute parser)

…uwer Rollup of 10 pull requests Successful merges: - #152364 (Port a lot of attributes to the new parser) - #151954 (Add help message suggesting explicit reference cast for From/TryFrom) - #152148 (Move `impl Interner for TyCtxt` to its own submodule) - #152226 (Modernize diagnostic for indeterminate trait object lifetime bounds) - #152351 (Remove `SubdiagMessage` in favour of the identical `DiagMessage`) - #152417 (Move the needs-drop check for `arena_cache` queries out of macro code) - #150688 (typeck: Make it clearer that `check_pat_lit` only handles literal patterns) - #152293 (Format heterogeneous try blocks) - #152355 (Update documentation of rustc_macros) - #152396 (Uplift `Predicate::allow_normalization` to `rustc_type_ir`)

Rollup merge of #152293 - ia0:try_blocks_heterogeneous, r=ytmimi Format heterogeneous try blocks The tracking issue for `try_blocks_heterogeneous` is #149488. This follows the formatting of homogeneous try blocks (feature `try_blocks`) by considering `try bikeshed <type>` to be the equivalent of `try` (in particular a single "token"). An alternative would be to permit breaking between `bikeshed` and `<type>`, but given that those 2 elements are an explicitly temporary part of the syntax, it doesn't seem worth it. There also doesn't seem to be any existing precedent breaking between a keyword and a type. It also doesn't seem to be useful in practice, given that the type itself doesn't break (which is how it works for the return type of closures) and has more chances to dominate the length in case a break is necessary. Happy to adapt anything in case this formatting is not optimal. The test is also copied from homogeneous try blocks with 2 additional test cases to demonstrate the behavior with long types. See [#t-lang > try blocks @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/try.20blocks/near/572387493) for context.

Format heterogeneous try blocks

03dcd99

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-rustfmt Relevant to the rustfmt team, which will review and decide on the PR/issue. labels Feb 7, 2026

rustbot assigned Mark-Simulacrum Feb 7, 2026

rustbot assigned ytmimi and unassigned Mark-Simulacrum Feb 7, 2026

ytmimi reviewed Feb 7, 2026

View reviewed changes

improve tests

d5c6866

rust-bors bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 10, 2026

matthiaskrgr mentioned this pull request Feb 10, 2026

Rollup of 7 pull requests #152421

Closed

JonathanBrouwer mentioned this pull request Feb 10, 2026

Rollup of 8 pull requests #152427

Closed

JonathanBrouwer mentioned this pull request Feb 10, 2026

Rollup of 11 pull requests #152429

Closed

JonathanBrouwer mentioned this pull request Feb 10, 2026

Rollup of 11 pull requests #152430

Closed

JonathanBrouwer mentioned this pull request Feb 10, 2026

Rollup of 10 pull requests #152437

Merged

rust-bors bot merged commit d9a8675 into rust-lang:main Feb 10, 2026
11 checks passed

rustbot added this to the 1.95.0 milestone Feb 10, 2026

Uh oh!

Conversation

ia0 commented Feb 7, 2026

Uh oh!

rustbot commented Feb 7, 2026

Uh oh!

rustbot commented Feb 7, 2026

Uh oh!

ytmimi commented Feb 7, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ytmimi commented Feb 10, 2026

Uh oh!

rust-bors bot commented Feb 10, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants