Fix ICE by rejecting const blocks in patterns during AST lowering (closes #148138) by Shinonn23 · Pull Request #149667 · rust-lang/rust

Shinonn23 · 2025-12-05T04:17:14Z

This PR fixes the ICE reported in #148138.

The root cause is that const blocks aren’t allowed in pattern position, but the AST lowering logic still attempted to create PatExprKind::ConstBlock, allowing invalid HIR to reach type checking and trigger a span_bug!.

Following the discussion in the issue, this patch removes the ConstBlock lowering path from lower_expr_within_pat. Any ExprKind::ConstBlock inside a pattern is now handled consistently with other invalid pattern expressions.

A new UI test is included to ensure the compiler reports a proper error and to prevent regressions.

Closes#148138.

rustbot · 2025-12-05T04:17:18Z

r? @SparrowLii

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

dianne · 2025-12-05T06:25:34Z

r? dianne

rustbot · 2025-12-05T07:22:53Z

rust-analyzer is developed in its own repository. If possible, consider making this change to rust-lang/rust-analyzer instead.

cc @rust-lang/rust-analyzer

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

Some changes occurred in match checking

cc @Nadrieril

Veykril

This should not need to touch rust-analyzer source

View changes since this review

…8, r=dianne Fix ICE by rejecting const blocks in patterns during AST lowering (closesrust-lang#148138) This PR fixes the ICE reported in rust-lang#148138. The root cause is that `const` blocks aren’t allowed in pattern position, but the AST lowering logic still attempted to create `PatExprKind::ConstBlock`, allowing invalid HIR to reach type checking and trigger a `span_bug!`. Following the discussion in the issue, this patch removes the `ConstBlock` lowering path from `lower_expr_within_pat`. Any `ExprKind::ConstBlock` inside a pattern is now handled consistently with other invalid pattern expressions. A new UI test is included to ensure the compiler reports a proper error and to prevent regressions. Closesrust-lang#148138.

…uwer Rollup of 8 pull requests Successful merges: - #148321 (parser/lexer: bump to Unicode 17, use faster unicode-ident) - #149540 (std: sys: fs: uefi: Implement readdir) - #149582 (Implement `Duration::div_duration_{floor,ceil}`) - #149663 (Optimized implementation for uN::{gather,scatter}_bits) - #149667 (Fix ICE by rejecting const blocks in patterns during AST lowering (closes#148138)) - #149947 (add several older crashtests) - #150011 (Add more `unbounded_sh[lr]` examples) - #150411 (refactor `destructure_const`) r? `@ghost` `@rustbot` modify labels: rollup

Rollup merge of #149667 - Shinonn23:fix-ice-constblock-148138, r=dianne Fix ICE by rejecting const blocks in patterns during AST lowering (closes#148138) This PR fixes the ICE reported in #148138. The root cause is that `const` blocks aren’t allowed in pattern position, but the AST lowering logic still attempted to create `PatExprKind::ConstBlock`, allowing invalid HIR to reach type checking and trigger a `span_bug!`. Following the discussion in the issue, this patch removes the `ConstBlock` lowering path from `lower_expr_within_pat`. Any `ExprKind::ConstBlock` inside a pattern is now handled consistently with other invalid pattern expressions. A new UI test is included to ensure the compiler reports a proper error and to prevent regressions. Closes#148138.

…8, r=dianne Fix ICE by rejecting const blocks in patterns during AST lowering (closesrust-lang#148138) This PR fixes the ICE reported in rust-lang#148138. The root cause is that `const` blocks aren’t allowed in pattern position, but the AST lowering logic still attempted to create `PatExprKind::ConstBlock`, allowing invalid HIR to reach type checking and trigger a `span_bug!`. Following the discussion in the issue, this patch removes the `ConstBlock` lowering path from `lower_expr_within_pat`. Any `ExprKind::ConstBlock` inside a pattern is now handled consistently with other invalid pattern expressions. A new UI test is included to ensure the compiler reports a proper error and to prevent regressions. Closesrust-lang#148138.

… r=lcnr cleanup: remove borrowck handling for inline const patterns rust-lang#120390 added borrow-checking for inline const patterns; a type annotation was added to inline const patterns in the THIR to remember the `DefId` and args of the constants so they could be checked and constraints could be propagated to their parents. As of rust-lang#138499 though, inline const patterns can't be borrow-checked due to a query cycle, and as of rust-lang#149667, the type/`DefId`/args annotations on inline const patterns have been removed, so the borrowck code for them seems unused; this PR removes it. In a hypothetical future where borrowck doesn't depend on exhaustiveness checking so `inline_const_pat` can be reinstated, I imagine we also won't be evaluating inline const patterns before borrowck. As such, we might be able to reuse the existing code for normal unevaluated inline const operands in [`TypeChecker::visit_operand`](https://github.com/rust-lang/rust/blob/32fe406b5e71afbb0d8b95280e50e67d1549224c/compiler/rustc_borrowck/src/type_check/mod.rs#L1720-L1749) (or at least we shouldn't need to encode inline const patterns' `DefId` and args in user type annotations if they appear directly in the MIR). r? lcnr

Rollup merge of #150817 - cleanup-inline-const-pat-borrowck, r=lcnr cleanup: remove borrowck handling for inline const patterns #120390 added borrow-checking for inline const patterns; a type annotation was added to inline const patterns in the THIR to remember the `DefId` and args of the constants so they could be checked and constraints could be propagated to their parents. As of #138499 though, inline const patterns can't be borrow-checked due to a query cycle, and as of #149667, the type/`DefId`/args annotations on inline const patterns have been removed, so the borrowck code for them seems unused; this PR removes it. In a hypothetical future where borrowck doesn't depend on exhaustiveness checking so `inline_const_pat` can be reinstated, I imagine we also won't be evaluating inline const patterns before borrowck. As such, we might be able to reuse the existing code for normal unevaluated inline const operands in [`TypeChecker::visit_operand`](https://github.com/rust-lang/rust/blob/32fe406b5e71afbb0d8b95280e50e67d1549224c/compiler/rustc_borrowck/src/type_check/mod.rs#L1720-L1749) (or at least we shouldn't need to encode inline const patterns' `DefId` and args in user type annotations if they appear directly in the MIR). r? lcnr

cleanup: remove borrowck handling for inline const patterns rust-lang/rust#120390 added borrow-checking for inline const patterns; a type annotation was added to inline const patterns in the THIR to remember the `DefId` and args of the constants so they could be checked and constraints could be propagated to their parents. As of rust-lang/rust#138499 though, inline const patterns can't be borrow-checked due to a query cycle, and as of rust-lang/rust#149667, the type/`DefId`/args annotations on inline const patterns have been removed, so the borrowck code for them seems unused; this PR removes it. In a hypothetical future where borrowck doesn't depend on exhaustiveness checking so `inline_const_pat` can be reinstated, I imagine we also won't be evaluating inline const patterns before borrowck. As such, we might be able to reuse the existing code for normal unevaluated inline const operands in [`TypeChecker::visit_operand`](https://github.com/rust-lang/rust/blob/32fe406b5e71afbb0d8b95280e50e67d1549224c/compiler/rustc_borrowck/src/type_check/mod.rs#L1720-L1749) (or at least we shouldn't need to encode inline const patterns' `DefId` and args in user type annotations if they appear directly in the MIR). r? lcnr

…expansion, r=fmease reject inline const patterns pre-expansion Reverts the parser changes from rust-lang#149667Fixesrust-lang#152499 Awkwardly, some cases of inline const pats can only be caught pre-expansion and some can only be caught post-expansion. rust-lang#149667 switched from only rejecting the former to only rejecting the latter.

Rollup merge of #152548 - dianne:reject-const-block-pat-pre-expansion, r=fmease reject inline const patterns pre-expansion Reverts the parser changes from #149667Fixes#152499 Awkwardly, some cases of inline const pats can only be caught pre-expansion and some can only be caught post-expansion. #149667 switched from only rejecting the former to only rejecting the latter.

…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

…uwer Rollup of 8 pull requests Successful merges: - rust-lang/rust#148321 (parser/lexer: bump to Unicode 17, use faster unicode-ident) - rust-lang/rust#149540 (std: sys: fs: uefi: Implement readdir) - rust-lang/rust#149582 (Implement `Duration::div_duration_{floor,ceil}`) - rust-lang/rust#149663 (Optimized implementation for uN::{gather,scatter}_bits) - rust-lang/rust#149667 (Fix ICE by rejecting const blocks in patterns during AST lowering (closesrust-lang/rust#148138)) - rust-lang/rust#149947 (add several older crashtests) - rust-lang/rust#150011 (Add more `unbounded_sh[lr]` examples) - rust-lang/rust#150411 (refactor `destructure_const`) r? `@ghost` `@rustbot` modify labels: rollup

rustbot assigned SparrowLii Dec 5, 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 Dec 5, 2025

reddevilmidzy reviewed Dec 5, 2025
View reviewed changes

Comment threadtests/ui/pattern/deref-patterns/ice-adjust-mode-unimplemented-for-constblock.rs Outdated

Shinonn23 force-pushed the fix-ice-constblock-148138 branch from dd08ea6 to b713916Compare December 5, 2025 05:38

dianne reviewed Dec 5, 2025
View reviewed changes

Comment threadcompiler/rustc_ast_lowering/src/pat.rs
Comment threadcompiler/rustc_ast_lowering/src/pat.rs

rustbot assigned dianne and unassigned SparrowLii Dec 5, 2025

Shinonn23 force-pushed the fix-ice-constblock-148138 branch from b713916 to 8a0d87bCompare December 5, 2025 07:22

rustbot added T-clippy Relevant to the Clippy team. T-rust-analyzer Relevant to the rust-analyzer team, which will review and decide on the PR/issue. labels Dec 5, 2025

This comment has been minimized.
Sign in to view

Shinonn23 force-pushed the fix-ice-constblock-148138 branch from 8a0d87b to e412043Compare December 5, 2025 07:25

This comment has been minimized.
Sign in to view

Shinonn23 force-pushed the fix-ice-constblock-148138 branch from e412043 to 3d5438dCompare December 5, 2025 07:26

dianne reviewed Dec 5, 2025
View reviewed changes

Comment threadoutput.txt Outdated

Veykril reviewed Dec 5, 2025
View reviewed changes

Shinonn23 force-pushed the fix-ice-constblock-148138 branch 2 times, most recently from 5260fe6 to d217779Compare December 5, 2025 07:54

This comment has been minimized.
Sign in to view

jieyouxu closed this Dec 5, 2025

rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Dec 5, 2025

jieyouxu reopened this Dec 5, 2025

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Dec 5, 2025

Shinonn23 force-pushed the fix-ice-constblock-148138 branch 2 times, most recently from 85231c0 to 37c37edCompare December 5, 2025 11:12

This comment has been minimized.
Sign in to view

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 28, 2025

This was referenced Dec 28, 2025
Rollup of 6 pull requests #150467
Closed
Rollup of 8 pull requests #150469
Merged

bors merged commit ef835a8 into rust-lang:mainDec 29, 2025
11 checks passed

rustbot added this to the 1.94.0 milestone Dec 29, 2025

Shinonn23 deleted the fix-ice-constblock-148138 branch December 29, 2025 18:54

dianne mentioned this pull request Jan 8, 2026
cleanup: remove borrowck handling for inline const patterns #150817
Merged

fmease mentioned this pull request Feb 11, 2026
Inline const patterns are no longer pre-expansion gated #152499
Closed

dianne mentioned this pull request Feb 12, 2026
reject inline const patterns pre-expansion #152548
Merged

fmease mentioned this pull request Mar 9, 2026
Ping fmease on parser modifications #153624
Merged

Navigation Menu

Uh oh!

Uh oh!

Fix ICE by rejecting const blocks in patterns during AST lowering (closes #148138) - #149667

Fix ICE by rejecting const blocks in patterns during AST lowering (closes #148138)#149667
bors merged 1 commit into
rust-lang:mainfrom
Shinonn23:fix-ice-constblock-148138

Shinonn23 commented Dec 5, 2025•
edited
Loading

Uh oh!

rustbot commented Dec 5, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

dianne commented Dec 5, 2025

Uh oh!

rustbot commented Dec 5, 2025

Uh oh!

This comment has been minimized.

This comment has been minimized.

Uh oh!

Veykril left a comment •
edited by rustbot
Loading

Uh oh!

This comment has been minimized.

This comment has been minimized.

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

10 participants

Uh oh!

Uh oh!

Conversation

Shinonn23 commented Dec 5, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Dec 5, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

dianne commented Dec 5, 2025

Uh oh!

rustbot commented Dec 5, 2025

Uh oh!

This comment has been minimized.

This comment has been minimized.

Uh oh!

Veykril left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

This comment has been minimized.

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

10 participants

Shinonn23 commented Dec 5, 2025•
edited
Loading

Veykril left a comment •
edited by rustbot
Loading