-
Notifications
You must be signed in to change notification settings - Fork 13k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
match lowering: Split finalize_or_candidate
into more coherent methods
#127917
Conversation
Some changes occurred in match lowering cc @Nadrieril |
LGTM, just one nit |
Only the last candidate can possibly have more match pairs, so this can be separate from the main or-candidate postprocessing loop.
// The remaining match pairs are all `Or`, so we can append them | ||
// without having to re-sort or-patterns to the end. | ||
leaf_candidate.match_pairs.extend(remaining_match_pairs.iter().cloned()); | ||
let or_start = leaf_candidate.pre_binding_block.unwrap(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Side note: I wonder if this use of pre_binding_block
should use Option::take
instead, because it's no longer meaningful as a pre-binding block. Some quick testing indicates that doing so doesn't make tests fail.
(I won't make that change in this PR, but maybe I'll look into it later.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Honestly, maybe. And same for the otherwise_block
that we use below, we may as well read it early.
Revised the comment about extending I left the |
Thank you! @bors r+ rollup |
match lowering: Split `finalize_or_candidate` into more coherent methods I noticed that `finalize_or_candidate` was responsible for several different postprocessing tasks, making it difficult to understand. This PR aims to clean up some of the confusion by: - Extracting `remove_never_subcandidates` from `merge_trivial_subcandidates` - Extracting `test_remaining_match_pairs_after_or` from `finalize_or_candidate` - Taking what remains of `finalize_or_candidate`, and inlining it into its caller --- Reviewing individual commits and ignoring whitespace is recommended. Most of the large-looking changes are just moving existing code around, mostly unaltered. r? `@Nadrieril`
match lowering: Split `finalize_or_candidate` into more coherent methods I noticed that `finalize_or_candidate` was responsible for several different postprocessing tasks, making it difficult to understand. This PR aims to clean up some of the confusion by: - Extracting `remove_never_subcandidates` from `merge_trivial_subcandidates` - Extracting `test_remaining_match_pairs_after_or` from `finalize_or_candidate` - Taking what remains of `finalize_or_candidate`, and inlining it into its caller --- Reviewing individual commits and ignoring whitespace is recommended. Most of the large-looking changes are just moving existing code around, mostly unaltered. r? ```@Nadrieril```
…iaskrgr Rollup of 6 pull requests Successful merges: - rust-lang#127463 ( use precompiled rustdoc with CI rustc) - rust-lang#127779 (Add a hook for `should_codegen_locally`) - rust-lang#127843 (unix: document unsafety for std `sig{action,altstack}`) - rust-lang#127873 (kmc-solid: `#![forbid(unsafe_op_in_unsafe_fn)]`) - rust-lang#127917 (match lowering: Split `finalize_or_candidate` into more coherent methods) - rust-lang#127964 (run_make_support: skip rustfmt for lib.rs) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#127917 - Zalathar:after-or, r=Nadrieril match lowering: Split `finalize_or_candidate` into more coherent methods I noticed that `finalize_or_candidate` was responsible for several different postprocessing tasks, making it difficult to understand. This PR aims to clean up some of the confusion by: - Extracting `remove_never_subcandidates` from `merge_trivial_subcandidates` - Extracting `test_remaining_match_pairs_after_or` from `finalize_or_candidate` - Taking what remains of `finalize_or_candidate`, and inlining it into its caller --- Reviewing individual commits and ignoring whitespace is recommended. Most of the large-looking changes are just moving existing code around, mostly unaltered. r? ``@Nadrieril``
I noticed that
finalize_or_candidate
was responsible for several different postprocessing tasks, making it difficult to understand.This PR aims to clean up some of the confusion by:
remove_never_subcandidates
frommerge_trivial_subcandidates
test_remaining_match_pairs_after_or
fromfinalize_or_candidate
finalize_or_candidate
, and inlining it into its callerReviewing individual commits and ignoring whitespace is recommended.
Most of the large-looking changes are just moving existing code around, mostly unaltered.
r? @Nadrieril