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

Refactor: Separate LocalRef variant for not-evaluated-yet operands #109582

Merged
merged 1 commit into from
Mar 27, 2023

Conversation

scottmcm
Copy link
Member

As I was reading through this, I noticed that almost every place that was using this needed to distinguish between Some vs None in the match arm anyway, so thought that separating the cases at the variant level might be clearer instead.

I like how it ended up; let me know what you think!

@rustbot
Copy link
Collaborator

rustbot commented Mar 25, 2023

r? @oli-obk

(rustbot has picked a reviewer for you, use r? to override)

@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 Mar 25, 2023
@@ -558,6 +558,9 @@ impl<'a, 'tcx, Bx: BuilderMethods<'a, 'tcx>> FunctionCx<'a, 'tcx, Bx> {
bug!("using operand local {:?} as place", place_ref);
}
}
LocalRef::PendingOperand => {
bug!("using still-pending operand local {:?} as place", place_ref);
Copy link
Member Author

@scottmcm scottmcm Mar 25, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the one place that wasn't already distinguishing between Some/None, and near as I can tell that's just because the None case is impossible -- at least it seems plausible that we should never be using a not-evaluated-yet operand as a place, and I never hit an ICE from a stage2 build nor any codegen tests having added this check.

@oli-obk
Copy link
Contributor

oli-obk commented Mar 27, 2023

@bors r+ rollup

nice!

@bors
Copy link
Contributor

bors commented Mar 27, 2023

📌 Commit 4979860 has been approved by oli-obk

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 Mar 27, 2023
@oli-obk
Copy link
Contributor

oli-obk commented Mar 27, 2023

@bors r+ rollup

nice!

@bors
Copy link
Contributor

bors commented Mar 27, 2023

💡 This pull request was already approved, no need to approve it again.

@bors
Copy link
Contributor

bors commented Mar 27, 2023

📌 Commit 4979860 has been approved by oli-obk

It is now in the queue for this repository.

bors added a commit to rust-lang-ci/rust that referenced this pull request Mar 27, 2023
…iaskrgr

Rollup of 7 pull requests

Successful merges:

 - rust-lang#108625 (More config.toml.example cleanups)
 - rust-lang#109418 (Rename 'src/bootstrap/native.rs' to llvm.rs)
 - rust-lang#109580 (Remove some stale FIXMEs in new solver)
 - rust-lang#109582 (Refactor: Separate `LocalRef` variant for not-evaluated-yet operands)
 - rust-lang#109650 (Remove Nilstrieb from review rotation)
 - rust-lang#109656 (Update cargo)
 - rust-lang#109658 (Backport 1.68.1 and 1.68.2 release notes to `master`)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 7f6b406 into rust-lang:master Mar 27, 2023
@rustbot rustbot added this to the 1.70.0 milestone Mar 27, 2023
@scottmcm scottmcm deleted the local-ref-pending branch March 27, 2023 17:29
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.

4 participants