Skip to content
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

Merged
merged 5 commits into from
Jul 20, 2024

Conversation

Zalathar
Copy link
Contributor

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

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jul 18, 2024
@rustbot
Copy link
Collaborator

rustbot commented Jul 18, 2024

Some changes occurred in match lowering

cc @Nadrieril

@Nadrieril
Copy link
Member

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();
Copy link
Contributor Author

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.)

Copy link
Member

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.

@Zalathar
Copy link
Contributor Author

Revised the comment about extending match_pairs (diff).

I left the extend as-is because it does provide some value, and the revised comment (plus spacing) should make things sufficiently clear.

@Nadrieril
Copy link
Member

Thank you!

@bors r+ rollup

@bors
Copy link
Contributor

bors commented Jul 20, 2024

📌 Commit 239037e has been approved by Nadrieril

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 20, 2024
tgross35 added a commit to tgross35/rust that referenced this pull request Jul 20, 2024
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`
tgross35 added a commit to tgross35/rust that referenced this pull request Jul 20, 2024
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```
bors added a commit to rust-lang-ci/rust that referenced this pull request Jul 20, 2024
…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
@bors bors merged commit d846e92 into rust-lang:master Jul 20, 2024
6 checks passed
@rustbot rustbot added this to the 1.81.0 milestone Jul 20, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Jul 20, 2024
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``
@Zalathar Zalathar deleted the after-or branch July 21, 2024 00:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants