Fix ICE-133117: multiple never-pattern arm doesn't have false_edge_start_block

[Shunpoco]

Fixes #133117 , and close fixes #133063 , fixes #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). 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). 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). 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.

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @oli-obk (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[compiler-errors]

cc @Nadrieril

[Nadrieril]

r? Nadrieril, thanks for doing this I'll have a look when I get a moment

[Shunpoco]

@rustbot review

[Nadrieril]

Looks good, thank you for investigating and fixing this :)

@bors r+

[bors]

📌 Commit 7275bdf has been approved by Nadrieril

It is now in the queue for this repository.

[Nadrieril]

@bors rollup