-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
[MIR] Add explicit SetDiscriminant StatementKind for deaggregating enums #35348
Conversation
r? @eddyb (rust_highfive has picked a reviewer for you, use r? to override) |
Why not a plain projection? Dealing with discriminant needn’t to be that specific. |
@@ -700,7 +700,7 @@ impl<'blk, 'tcx> Drop for OwnedBuilder<'blk, 'tcx> { | |||
} | |||
|
|||
pub struct BlockAndBuilder<'blk, 'tcx: 'blk> { | |||
bcx: Block<'blk, 'tcx>, | |||
pub bcx: Block<'blk, 'tcx>, |
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.
This should be done via the with_bcx
method.
@nagisa How would that work? The discriminant is not always present in memory (e.g. nullable ptr). |
You can still conjure a ValueRef for what would be a discriminant in a nullable pointer, although, sure, reading and writing to such projection would need a little bit special care. |
@nagisa It's not just special care, it's not a valid lvalue. Lvalues are lvalues because they can be uniformly represented by pointers. |
Okay, so here’re my thoughts: First of all, it seems to me that @eddyb I still do not really see your point, so I’ll write down it for myself case-by-case (I’m using
It seems to me that generating MIR for special cases I wrote down is not any more complex than generating SetDiscriminant, really, and in trans, you can still handle this projection by abusing pattern matching and matching on |
@nagisa initially I thought it should be a projection, but consider that you can borrow lvalues -- what you do for This is why when @scottcarr and I were talking, we agreed that having a |
Ah, here is one other reason. Using a statement like this, we can very easily guarantee (via the MIR definition) that the variant is always statically known. This is important because we want things like |
StatementKind::SetDiscriminant{ .. } => { | ||
// SCOTT FIXME | ||
// is this right? | ||
bb_ctxt.builder.create_move_path() |
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.
I think you call just call span_bug!(...)
here. Borrowck is operating before any discriminant operations are introduced.
@bors r+ |
📌 Commit 374a203 has been approved by |
@bors r+ |
📌 Commit c39b040 has been approved by |
⌛ Testing commit c39b040 with merge bbf055a... |
⛄ The build was interrupted to prioritize another pull request. |
⌛ Testing commit c39b040 with merge 1480bcf... |
💔 Test failed - auto-mac-64-opt |
@bors r+ |
📌 Commit 3ada7a5 has been approved by |
998f2f3
to
e264e36
Compare
e264e36
to
d77a136
Compare
@bors r+ |
📌 Commit d77a136 has been approved by |
…akis [MIR] Add explicit SetDiscriminant StatementKind for deaggregating enums cc rust-lang#35186 To deaggregate enums, we need to be able to explicitly set the discriminant. This PR implements a new StatementKind that does that. I think some of the places that have `panics!` now could maybe do something smarter.
⌛ Testing commit d77a136 with merge e64f688... |
[MIR] Add explicit SetDiscriminant StatementKind for deaggregating enums cc #35186 To deaggregate enums, we need to be able to explicitly set the discriminant. This PR implements a new StatementKind that does that. I think some of the places that have `panics!` now could maybe do something smarter.
cc #35186
To deaggregate enums, we need to be able to explicitly set the discriminant. This PR implements a new StatementKind that does that.
I think some of the places that have
panics!
now could maybe do something smarter.