ICE: leaf_candidate.false_edge_start_block.is_some() duplicate match arm
#133117
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-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.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
|
@rustbot claim |
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
Code
Meta
rustc --version --verbose:Error output
Backtrace
The text was updated successfully, but these errors were encountered: