ICE: compiler/rustc_mir_build/src/build/matches/mod.rs None
#133063
Assignees
Labels
A-MIR
Area: Mid-level IR (MIR) - https://blog.rust-lang.org/2016/04/19/MIR.html
A-patterns
Relating to patterns and pattern matching
C-bug
Category: This is a bug.
F-if_let_guard
`#![feature(if_let_guard)]`
F-never_patterns
`#![feature(never_patterns)]`
I-ICE
Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
S-bug-has-test
Status: This bug is tracked inside the repo by a `known-bug` test.
S-has-bisection
Status: a bisection has been found for this issue
S-has-mcve
Status: A Minimal Complete and Verifiable Example has been found for this issue
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
matthiaskrgr
added
C-bug
rustbot
added
needs-triage
|
This bisects to #127159 cc @Nadrieril |
|
smaller fn main() {
match () {
(! | !) if let _ = Some(0) => {}
_ => {}
}
} |
jieyouxu
added
S-has-mcve
|
Smaller and type-correct: fn foo(x: !) {
match x {
(! | !) if false => {}
_ => {}
}
} |
matthiaskrgr
added
the
S-bug-has-test
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Jan 22, 2025
…lse-edge-start-block, r=Nadrieril Fix ICE-133117: multiple never-pattern arm doesn't have false_edge_start_block Fixes rust-lang#133117 , and close fixes rust-lang#133063 , fixes rust-lang#130779 In order to fix ICE-133117, at first I needed to tackle to ICE-133063 (this fixed 130779 as well). ### ICE-133063 and ICE-130779 This ICE is caused by those steps: 1. An arm has or-pattern, and all of the sub-candidates are never-pattern 2. In that case, all sub-candidates are removed in remove_never_subcandidates(). So the arm (candidate) has no sub-candidate. 3. In the current implementation, if there is no sub-candidate, the function assigns `pre_binding_block` into the candidate ([here](https://github.com/rust-lang/rust/blob/master/compiler/rustc_mir_build/src/builder/matches/mod.rs#L2002-L2004)). However, otherwise_block should be assigned to the candidate as well, because the otherwise_block is unwrapped in multiple place (like in lower_match_tree()). As a result, it causes the panic. I simply added the same block as pre_binding_block into otherwise_block, but I'm wondering if there is a better block to assign to otherwise_block (is it ok to assign the same block into pre_binding and otherwise?) ### ICE-133117 This is caused by those steps: 1. There are two arms, both are or-pattern and each has one match-pair (in the test code, both are `(!|!)`), and the second arm has a guard. 2. In match_candidate() for the first arm, it expands the second arm’s sub-candidates as well ([here](https://github.com/rust-lang/rust/blob/master/compiler/rustc_mir_build/src/builder/matches/mod.rs#L1800-L1805)). As a result, the root candidate of the second arm is not evaluated/modified in match_candidate(). So a false_edge_start_block is not assigned to the candidate. 3. merge_trivial_subcandidates() is called against the candidate for the second arm. It just returns immediately because the candidate has a guard. So a flase_edge_start_block is not assigned to the candidate also in this function. 4. remove_never_subcandidates() is called against the candidate. Since all sub-candidates are never-pattern. they are removed. 5. In lower_match_tree(), since there is no sub-candidate for the candidate, the candidate itself is evaluated in visit_leave_rev ([here](https://github.com/rust-lang/rust/blob/master/compiler/rustc_mir_build/src/builder/matches/mod.rs#L1532)). Because the candidate has no false_edge_start_block, it causes the panic. So I modified the order of if blocks in merge_trivial_subcandidates() to assign a false_edge_start_block if the candidate doesn't have.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
auto-reduced (treereduce-rust):
original:
Version information
Possibly related line of code:
rust/compiler/rustc_mir_build/src/build/matches/mod.rs
Lines 1534 to 1546 in 251dc8a
Command:
/home/matthias/.rustup/toolchains/master/bin/rustcProgram output
@rustbot label +F-if_let_guard
The text was updated successfully, but these errors were encountered: