Experimentally add *heterogeneous* `try` blocks by scottmcm · Pull Request #149489 · rust-lang/rust

scottmcm · 2025-11-30T22:49:38Z

#148725 moved the default to being homogeneous; this adds heterogeneous ones back under an obvious-bikeshed syntax so people can experiment with that as well.

Essentially resolves #149025 by letting them move to this syntax instead.

New tracking issue: #149488
Related RFC: rust-lang/rfcs#3721 (comment) (specifically about experimenting)

rustbot · 2025-11-30T22:49:44Z

r? @nnethercote

rustbot has assigned @nnethercote.
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

rustbot · 2025-11-30T23:09:49Z

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

rustbot · 2025-11-30T23:36:00Z

Some changes occurred in src/tools/rustfmt

cc @rust-lang/rustfmt

nnethercote · 2025-12-09T06:59:20Z

compiler/rustc_ast_lowering/src/lib.rs


+#[derive(Copy, Clone, Debug)]
+enum TryBlockScope {
+    /// There isn't a `try` block, so the scope is the function or closure or ...


It took me a few reads to understand this comment. Can it be rephrased? What other possibilities are there?

nnethercote · 2025-12-09T07:03:34Z

compiler/rustc_ast/src/ast.rs

-    /// A try block (`try { ... }`).
-    TryBlock(Box<Block>),
+    /// A try block (`try { ... }`), if the type is `None`, or
+    /// A try block (`try bikeshed Ty { ... }`) if the type is `Some`.


Nowhere in the PR is an explanation that bikeshed is deliberately ridiculous placeholder syntax. (I assume that's what it is.) Probably worth mentioning at least once. This might be a good spot for it.

nnethercote · 2025-12-09T07:04:39Z

Standard plumbing, mostly, seems fine.

r=me with the nits addressed.

148725 moved the default to being homogeneous; this adds heterogeneous ones back under an obvious-bikeshed syntax so people can experiment with that as well. Essentially resolves 149025 by letting them move to this syntax instead.

rustbot · 2025-12-10T04:18:56Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

scottmcm · 2025-12-10T05:46:01Z

@bors r=nnethercote

bors · 2025-12-10T05:46:04Z

📌 Commit 35598c1 has been approved by nnethercote

It is now in the queue for this repository.

nxsaken · 2025-12-10T12:46:13Z

compiler/rustc_ast_lowering/src/lib.rs

+    /// We're inside a `try { … }` block, so a `?` will block-break
+    /// from that block using a type depending only on the argument.
+    Homogeneous(HirId),
+    /// We're inside a `try as _ { … }` block, so a `?` will block-break


Suggested change

/// We're inside a `try as _ { … }` block, so a `?` will block-break

/// We're inside a `try bikeshed _ { … }` block, so a `?` will block-break

nxsaken · 2025-12-10T12:50:37Z

compiler/rustc_ast/src/visit.rs

+                ExprKind::TryBlock(body, optional_type) =>
+                    visit_visitable!($($mut)? vis, body, optional_type),


Suggested change

ExprKind::TryBlock(body, optional_type) =>

visit_visitable!($($mut)? vis, body, optional_type),

ExprKind::TryBlock(body, opt_ty) =>

visit_visitable!($($mut)? vis, body, opt_ty),

(For simpler searching, since other places use opt_ty.)

Rollup of 7 pull requests Successful merges: - #148052 (Stabilize `const_mul_add`) - #149386 (Display funding link in the github overview) - #149489 (Experimentally add *heterogeneous* `try` blocks) - #149764 (Make `--print=backend-has-zstd` work by default on any backend) - #149838 (Build auxiliary in pretty tests) - #149839 (Use `PointeeSized` bound for `TrivialClone` impls) - #149846 (Statically require links to an issue or the edition guide for all FCWs) r? `@ghost` `@rustbot` modify labels: rollup

Rollup merge of #149489 - scottmcm:try-bikeshed, r=nnethercote Experimentally add *heterogeneous* `try` blocks #148725 moved the default to being homogeneous; this adds heterogeneous ones back under an obvious-bikeshed syntax so people can experiment with that as well. Essentially resolves #149025 by letting them move to this syntax instead. New tracking issue: #149488 Related RFC: rust-lang/rfcs#3721 (comment) (specifically about experimenting)

Experimentally add *heterogeneous* `try` blocks rust-lang#148725 moved the default to being homogeneous; this adds heterogeneous ones back under an obvious-bikeshed syntax so people can experiment with that as well. Essentially resolves rust-lang#149025 by letting them move to this syntax instead. New tracking issue: rust-lang#149488 Related RFC: rust-lang/rfcs#3721 (comment) (specifically about experimenting)

Rollup of 7 pull requests Successful merges: - rust-lang/rust#148052 (Stabilize `const_mul_add`) - rust-lang/rust#149386 (Display funding link in the github overview) - rust-lang/rust#149489 (Experimentally add *heterogeneous* `try` blocks) - rust-lang/rust#149764 (Make `--print=backend-has-zstd` work by default on any backend) - rust-lang/rust#149838 (Build auxiliary in pretty tests) - rust-lang/rust#149839 (Use `PointeeSized` bound for `TrivialClone` impls) - rust-lang/rust#149846 (Statically require links to an issue or the edition guide for all FCWs) r? `@ghost` `@rustbot` modify labels: rollup

…r=fmease Ping fmease on parser modifications From time to time innocuous-seeming PRs get submitted and sometimes even approved that unbeknownst to their author and to reviewers change the grammar of (stable) Rust which would be a breaking change; often they only meant to tweak diagnostics. I sometimes catch such PRs before they get merged but I want to make it a lot harder for them to slip through the cracks going forward. I'm going to list recent examples to paint a picture (note: this is not about blame!): 1. rust-lang#149728 (review) (2026) * caught before merge but after approval * PR unapproved for now 2. rust-lang#152501 (2026) * caught after merge of rust-lang#149489 * fixed & backported 3. rust-lang#152499 (2026) * caught after merge of rust-lang#149667 * fixed & backported 4. rust-lang#151960 (comment) (2026) * caught right after submission * the approach was thus changed 5. rust-lang#148238 (2025) * caught after merge of rust-lang#118947 * still unaddressed 6. rust-lang#144386 (review) (2025) * caught right after submission * crater & T-lang were activated by me 7. rust-lang#119042 (comment) (2023) * caught right after submission * the approach was thus changed 8. rust-lang#103534 (2022) * caught way later * partially addressed Why not just post a note without pinging me? Well, due to them not failing CI and generally due to (friendly) botspam, such comments just get lost or sometimes even actively ignored. Of course, I'm not able to catch everything. E.g., I didn't notice issue rust-lang#146417 before PR rust-lang#139858 was merged despite having skimmed its diff and more importantly, I as a reviewer missed the blatantly obvious rust-lang#144958 before merge. Separately, off and on over the span of one year I've worked on a Rust parser that now has >99% accuracy/parity with rustc according to some metrics (this includes stable + unstable + internal syntax) and which I'm using to detect such regressions and issues in general among other things (e.g., rust-lang#152499 and rust-lang#152820 were found this way, more to come). I'm pretty invested, let's say. r? me

…r=fmease Ping fmease on parser modifications From time to time innocuous-seeming PRs get submitted and sometimes even approved that unbeknownst to their author and to reviewers change the grammar of (stable) Rust which would be a breaking change; often they only meant to tweak diagnostics. I sometimes catch such PRs before they get merged but I want to make it a lot harder for them to slip through the cracks going forward. I'm going to list recent examples to paint a picture (note: this is not about blame!): 1. rust-lang#149728 (review) (2026) * caught before merge but after approval * PR unapproved for now 2. rust-lang#152501 (2026) * caught after merge of rust-lang#149489 * fixed & backported 3. rust-lang#152499 (2026) * caught after merge of rust-lang#149667 * fixed & backported 4. rust-lang#151960 (comment) (2026) * caught right after submission * the approach was thus changed 5. rust-lang#148238 (2025) * caught after merge of rust-lang#118947 * still unaddressed 6. rust-lang#144386 (review) (2025) * caught right after submission * crater & T-lang were activated by me 7. rust-lang#119042 (comment) (2023) * caught right after submission * the approach was thus changed 8. rust-lang#103534 (2022) * caught way later * partially addressed Why not just post a note without pinging me? Well, due to them not failing CI and generally due to (friendly) botspam, such comments just get lost or sometimes even actively ignored. Of course, I'm not able to catch everything. E.g., I didn't notice issue rust-lang#146417 before PR rust-lang#139858 was merged despite having skimmed its diff and more importantly, I as a reviewer missed the blatantly obvious rust-lang#144958 before merge. Separately, off and on over the span of one year I've worked on a Rust parser that now has >99% accuracy/parity with rustc according to some metrics (this includes stable + unstable + internal syntax) and which I'm now using to detect such regressions and issues in general among other things (e.g., rust-lang#152499 and rust-lang#152820 were found this way, more to come). I'm pretty invested, let's say. r? me

Rollup merge of #153624 - fmease:ping-me-on-parser-changes, r=fmease Ping fmease on parser modifications From time to time innocuous-seeming PRs get submitted and sometimes even approved that unbeknownst to their author and to reviewers change the grammar of (stable) Rust which would be a breaking change; often they only meant to tweak diagnostics. I sometimes catch such PRs before they get merged but I want to make it a lot harder for them to slip through the cracks going forward. I'm going to list recent examples to paint a picture (note: this is not about blame!): 1. #149728 (review) (2026) * caught before merge but after approval * PR unapproved for now 2. #152501 (2026) * caught after merge of #149489 * fixed & backported 3. #152499 (2026) * caught after merge of #149667 * fixed & backported 4. #151960 (comment) (2026) * caught right after submission * the approach was thus changed 5. #148238 (2025) * caught after merge of #118947 * still unaddressed 6. #144386 (review) (2025) * caught right after submission * crater & T-lang were activated by me 7. #119042 (comment) (2023) * caught right after submission * the approach was thus changed 8. #103534 (2022) * caught way later * partially addressed Why not just post a note without pinging me? Well, due to them not failing CI and generally due to (friendly) botspam, such comments just get lost or sometimes even actively ignored. Of course, I'm not able to catch everything. E.g., I didn't notice issue #146417 before PR #139858 was merged despite having skimmed its diff and more importantly, I as a reviewer missed the blatantly obvious #144958 before merge. Separately, off and on over the span of one year I've worked on a Rust parser that now has >99% accuracy/parity with rustc according to some metrics (this includes stable + unstable + internal syntax) and which I'm now using to detect such regressions and issues in general among other things (e.g., #152499 and #152820 were found this way, more to come). I'm pretty invested, let's say. r? me

rustbot assigned nnethercote Nov 30, 2025

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Nov 30, 2025

This was referenced Nov 30, 2025

Possible try blocks regression in nightly #149025

Closed

Experimental Tracking Issue for Heterogeneous Try Blocks #149488

Open

This comment has been minimized.

Sign in to view

rustbot added the T-clippy Relevant to the Clippy team. label Nov 30, 2025

scottmcm mentioned this pull request Nov 30, 2025

Add homogeneous_try_blocks RFC rust-lang/rfcs#3721

Open

This comment has been minimized.

Sign in to view

rustbot added the T-rustfmt Relevant to the rustfmt team, which will review and decide on the PR/issue. label Nov 30, 2025

nnethercote approved these changes Dec 9, 2025

View reviewed changes

nnethercote added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Dec 9, 2025

scottmcm added 3 commits December 9, 2025 20:18

Experimentally add *heterogeneous* try blocks

4033d19

148725 moved the default to being homogeneous; this adds heterogeneous ones back under an obvious-bikeshed syntax so people can experiment with that as well. Essentially resolves 149025 by letting them move to this syntax instead.

Update clippy for the ast TryBlock change

f9e1031

Also get rustfmt to at least compile

35598c1

scottmcm force-pushed the try-bikeshed branch from 348490d to 35598c1 Compare December 10, 2025 04:18

bors 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-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Dec 10, 2025

nxsaken reviewed Dec 10, 2025

View reviewed changes

matthiaskrgr mentioned this pull request Dec 10, 2025

Rollup of 7 pull requests #149853

Merged

bors merged commit 02a58a9 into rust-lang:main Dec 10, 2025
11 checks passed

rustbot added this to the 1.94.0 milestone Dec 10, 2025

github-actions bot mentioned this pull request Dec 12, 2025

Toolchain upgrade to nightly-2026-02-09 flux-rs/flux#1345

Open

rust-timer mentioned this pull request Dec 12, 2025

Rollup of 7 pull requests #149909

Merged

goffrie mentioned this pull request Feb 2, 2026

Implement the new homogeneous & heterogeneous try blocks rust-lang/rust-analyzer#21572

Merged

fmease mentioned this pull request Feb 12, 2026

try bikeshed $ty { … } is not pre-expansion gated (affects beta+nightly) #152501

Closed

fmease mentioned this pull request Mar 9, 2026

Ping fmease on parser modifications #153624

Merged

	/// We're inside a `try as _ { … }` block, so a `?` will block-break
	/// We're inside a `try bikeshed _ { … }` block, so a `?` will block-break

		ExprKind::TryBlock(body, optional_type) =>
		visit_visitable!($($mut)? vis, body, optional_type),

Uh oh!

Conversation

scottmcm commented Nov 30, 2025 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Nov 30, 2025

Uh oh!

This comment has been minimized.

rustbot commented Nov 30, 2025

Uh oh!

This comment has been minimized.

rustbot commented Nov 30, 2025

Uh oh!

nnethercote Dec 9, 2025

Choose a reason for hiding this comment

Uh oh!

nnethercote Dec 9, 2025

Choose a reason for hiding this comment

Uh oh!

nnethercote commented Dec 9, 2025

Uh oh!

rustbot commented Dec 10, 2025

Uh oh!

scottmcm commented Dec 10, 2025

Uh oh!

bors commented Dec 10, 2025

Uh oh!

nxsaken Dec 10, 2025

Choose a reason for hiding this comment

Uh oh!

nxsaken Dec 10, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

scottmcm commented Nov 30, 2025 •

edited by rustbot

Loading