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

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

tests/ui/pattern/deref-patterns/ice-adjust-mode-unimplemented-for-constblock.rs

compiler/rustc_ast_lowering/src/pat.rs

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

output.txt

Veykril

This should not need to touch rust-analyzer source

View changes since this review

dianne · 2025-12-21T03:59:01Z

compiler/rustc_mir_build/src/thir/pattern/mod.rs

-            hir::PatExprKind::ConstBlock(anon_const) => {
-                self.lower_inline_const(anon_const, expr.hir_id, expr.span)
-            }


That's a good point. There's a handful of other references to inline const patterns in comments as well, e.g. in pattern lowering and checking code, as well as on the definition of thir::PatKind::ExpandedConstant.

dianne · 2025-12-21T04:09:21Z

compiler/rustc_mir_build/src/thir/pattern/mod.rs

-            infcx.canonicalize_user_type_annotation(ty::UserType::new(ty::UserTypeKind::TypeOf(
-                def_id.to_def_id(),
-                ty::UserArgs { args, user_self_ty: None },
-            )))
-        };
-        let annotation =
-            CanonicalUserTypeAnnotation { user_ty: Box::new(annotation), span, inferred_ty: ty };
-        PatKind::AscribeUserType {
-            subpattern: pattern,
-            ascription: Ascription {
-                annotation,
-                // Note that we use `Contravariant` here. See the `variance` field documentation
-                // for details.
-                variance: ty::Contravariant,
-            },


We might also be able to remove the code that uses the ascriptions this applied. I noticed a mention of inline const patterns in a span_bug! in the MIR type checker:

rust/compiler/rustc_borrowck/src/type_check/mod.rs

Lines 577 to 583 in cb79c42

span_bug!(

span,

"bad inline const pattern: ({:?} = {:?}) {:?}",

const_ty,

inferred_ty,

terr

);

and after doing a little digging, I think the surrounding code is what uses those. It was added in #120390. Of course, I'd want someone more familiar with borrowck internals than myself to look at that. It might make more sense for a follow-up PR.

It might make more sense for a follow-up PR.

Yeah, I think it's fine to leave further cleanup to a later PR, to avoid scope-creeping this one.

dianne · 2025-12-21T05:44:04Z

@Shinonn23 The commit description still seems to be out of date. Could you fix it? I know this is nit-picky, but I'd like to to be correct before merging ^^

The patch itself looks good though! I think further cleanup and comment fixes can be left for followup work.

This fixes the ICE reported by rejecting `const` blocks in pattern position during AST lowering. Previously, `ExprKind::ConstBlock` could reach HIR as `PatExprKind::ConstBlock`, allowing invalid patterns to be type-checked and triggering an ICE. This patch removes the lowering path for const blocks in patterns and emits a proper diagnostic instead. A new UI test is added to ensure the compiler reports a regular error and to prevent regressions.

dianne · 2025-12-28T21:04:56Z

@bors r+

bors · 2025-12-28T21:04:59Z

📌 Commit a9442b4 has been approved by dianne

It is now in the queue for this repository.

…8, r=dianne Fix ICE by rejecting const blocks in patterns during AST lowering (closes rust-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. Closes rust-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 (closes rust-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. Closes rust-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

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

tests/ui/pattern/deref-patterns/ice-adjust-mode-unimplemented-for-constblock.rs Outdated Show resolved Hide resolved

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

dianne reviewed Dec 5, 2025

View reviewed changes

compiler/rustc_ast_lowering/src/pat.rs Show resolved Hide resolved

compiler/rustc_ast_lowering/src/pat.rs Show resolved Hide resolved

rustbot assigned dianne and unassigned SparrowLii Dec 5, 2025

Shinonn23 force-pushed the fix-ice-constblock-148138 branch from b713916 to 8a0d87b Compare 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