-
Notifications
You must be signed in to change notification settings - Fork 13.2k
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
Remove assertion on reachable blocks w/o results #12095
Conversation
@huonw r? |
I don't consider myself familiar enough with trans to review this, although I know many others have been running around in trans lately. There's a whole bunch of test cases in #11709 and they all look pretty small, so perhaps you could expand the test case a bit? |
} | ||
|
||
if b.expr.is_some() { | ||
bcx = expr::trans_into(bcx, b.expr.unwrap(), dest); |
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.
Why turn it into an if
with .unwrap
when you can just keep it "nice" with a match
?
match b.expr {
Some(e) => {
bcx = expr::trans_into(bcx, e, dst);
}
None => {}
}
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.
Fewer lines of code. Would there be a benefit from using match
instead of if
here?
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.
When you have a functional language, it's good to make use of it :)
You're checking for Some
twice (is_some
and unwrap
), and while LLVM will do its magic, it's generally a code smell to structure code this way.
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'll change it back then, thanks!
I'm no fan of dest::Ignore (I'd like to rip it out) -- but I think what is SUPPOSED to happen for a block with a unit result is that we switch over to "Ignore" output mode. I wonder why that's not happening here. Still, I imagine that this change is harmless. |
I'll investigate this a bit further |
@nikomatsakis @alexcrichton instead of removing the asserition, I added a check where |
@flaper87 as @alexcrichton said, there are several more test cases on #11709, e.g. adding the line Also, #11865 hits the same assertion; does this fix it? |
@huonw @alexcrichton ops sorry about that, I didn't mean to ignore that comment. Let me add those tests there. |
@flaper87 what additional information would trans_block need? |
@flaper87 in particular it seems like trans_block could easily check what its own output type is and so on. Might be more robust. (I would like to remove Ignore mode though...feels like it's a complex invariant we're maintaining and I'm not clear on exactly why) |
@nikomatsakis Agreed, callers would always pass a W.r.t removing |
I'd leave that for a separate patch -- also, what I had in mind was |
(r+ with the assertion I mentioned) |
@nikomatsakis done, Thanks! |
Feel free to |
…icola Increase defalt chalk overflow depth to match max solver size TBC: - rust-lang#12279: ok above 480 - ~~rust-lang#12182~~ - ~~rust-lang#12095~~ - rust-lang#11902: ok above 350 - ~~rust-lang#11668~~ - rust-lang#11370: ok above 450 - rust-lang#9754: probably ok above 250 (!), and the code in cause and branch are gone Closes rust-lang#12279 Closes rust-lang#11902 Closes rust-lang#11370 Closes rust-lang#9754
Closes #11709