-
Notifications
You must be signed in to change notification settings - Fork 13.4k
match lowering: Split finalize_or_candidate
into more coherent methods
#127917
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
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