Skip to content

[MIR] Get rid of that nasty unit_ty temporary lval #30635

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

Merged
merged 2 commits into from
Jan 12, 2016

Conversation

nagisa
Copy link
Member

@nagisa nagisa commented Dec 30, 2015

Get rid of that nasty unit_ty temporary variable created just because it might be handy to have one around, when in reality it isn’t really that useful at all.

r? @nikomatsakis

Fixes #30637

@nagisa nagisa force-pushed the mir-rid-unit-temp branch 2 times, most recently from 54cbd58 to d3d1316 Compare December 30, 2015 18:03
let unit_temp = this.unit_temp.clone();
let body_block_end = unpack!(this.into(&unit_temp, body_block, body));
// FIXME(#30636): this should not create or request any sort of destination at
// all.
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not sure I agree with this FIXME. In trans-land, we have some special cases for "ignoring" the result and it's kind of a pain. I guess though that we could have a special mode here just for blocks, maybe.

Copy link
Contributor

Choose a reason for hiding this comment

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

Also, I'm mildly worried that writing to destination here will yield incorrect results for the initialization analysis, once we implement that. Seems like something like:

let x;
x = while foo { ... /* try to use `x` in here */ }

might succeed when it shouldn't. But hmm that particular example I guess would not, since there is at least one iteration (the first one) where the body has not executed, and thus has not written into destination. Hmm, I guess it's ok.

@nagisa nagisa force-pushed the mir-rid-unit-temp branch from d3d1316 to 5d8b3a3 Compare January 6, 2016 20:21
unpack!(block = this.stmts(block, stmts));
this.into(destination, block, expr)
match expr {
Some(expr) => this.into(destination, block, expr),
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we still need the impl of EvalInto for Option<ExprRef<'tcx>>? I suspect not. In any case I think perhaps we ought to remove it, since it's ambiguous what should happen on None.

@nikomatsakis
Copy link
Contributor

r+ modulo the 2 nits

@nagisa nagisa force-pushed the mir-rid-unit-temp branch 2 times, most recently from 8d19c56 to 8d3c613 Compare January 6, 2016 21:18
@nagisa
Copy link
Member Author

nagisa commented Jan 6, 2016

Addressing the comments resulted in more changes (see ExprKind::If and ExprKind::Return (similar bugfix to the block one)), so I’m requesting a re-review.

Assign a default unit value to the destinations of block expressions without trailing expression,
return expressions without return value (i.e. `return;`) and conditionals without else clause.
@nagisa nagisa force-pushed the mir-rid-unit-temp branch from 8d3c613 to 3692ab6 Compare January 7, 2016 00:14
@nikomatsakis
Copy link
Contributor

@bors r+

@bors
Copy link
Collaborator

bors commented Jan 11, 2016

📌 Commit 3692ab6 has been approved by nikomatsakis

@bors
Copy link
Collaborator

bors commented Jan 12, 2016

⌛ Testing commit 3692ab6 with merge d6cb279...

bors added a commit that referenced this pull request Jan 12, 2016
Get rid of that nasty unit_ty temporary variable created just because it might be handy to have one around, when in reality it isn’t really that useful at all.

r? @nikomatsakis

Fixes #30637
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants