Skip to content

Conversation

@ia0
Copy link
Contributor

@ia0 ia0 commented Feb 7, 2026

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
Copy link
Collaborator

rustbot commented Feb 7, 2026

Some changes occurred in src/tools/rustfmt

cc @rust-lang/rustfmt

@rustbot 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
Copy link
Collaborator

rustbot commented Feb 7, 2026

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
Copy link
Contributor

ytmimi commented Feb 7, 2026

r? @ytmimi

@rustbot rustbot assigned ytmimi and unassigned Mark-Simulacrum Feb 7, 2026
// 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 ";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've also fixed try_block.rs.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks I appreciate that 🙏🏼

.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} ");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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} {
}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@ytmimi
Copy link
Contributor

ytmimi commented Feb 10, 2026

#![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
Copy link
Contributor

rust-bors bot commented Feb 10, 2026

📌 Commit d5c6866 has been approved by ytmimi

It is now in the queue for this repository.

@rust-bors 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 added a commit to matthiaskrgr/rust that referenced this pull request Feb 10, 2026
…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.
rust-bors bot pushed a commit that referenced this pull request Feb 10, 2026
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`)
JonathanBrouwer added a commit to JonathanBrouwer/rust that referenced this pull request Feb 10, 2026
…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.
JonathanBrouwer added a commit to JonathanBrouwer/rust that referenced this pull request Feb 10, 2026
…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.
JonathanBrouwer added a commit to JonathanBrouwer/rust that referenced this pull request Feb 10, 2026
…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.
rust-bors bot pushed a commit that referenced this pull request Feb 10, 2026
…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)
rust-bors bot pushed a commit that referenced this pull request Feb 10, 2026
…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`)
@rust-bors rust-bors bot merged commit d9a8675 into rust-lang:main Feb 10, 2026
11 checks passed
@rustbot rustbot added this to the 1.95.0 milestone Feb 10, 2026
rust-timer added a commit that referenced this pull request Feb 10, 2026
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-rustfmt Relevant to the rustfmt team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants