-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Rust fails to optimize away useless unwrap check #57166
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
Comments
Minimal example This no-op pub fn foo(x: String) -> String {
Some(x).unwrap()
} generates
On playground for the latest nightly (2019-07-14 83e4eed) |
That reminds me that this issue may be from the enum size optimization. When we don't have a separate field for the enum tag (in case like To prove that, an even simpler testcase is: use std::num::NonZeroUsize;
pub fn foo(x: NonZeroUsize) -> NonZeroUsize {
Some(x).unwrap()
} which produces the following assembly:
|
Hope that this will be improved soon considering the broad use of |
Slapping Works for String and NonZeroUsize examples, but not for first message (this is -Zmir-enable-passes=+DataflowConstProp) |
The minimized examples have been fixed since 1.77. I'm not completely certain that we have codegen tests for these. But the original example still has the missing optimizations as described. |
Here's a new MCVE: pub fn foo() -> usize {
let r = None..Some(30);
return r.end.unwrap();
} |
Hmm, the @lolbinarycat Please include a godbolt or playground link with a repro. That works fine when I try it https://rust.godbolt.org/z/cnznoG4K4 |
See the following code:
Apparently the
unwrap
should never panic given the assignment in the previous line. However, based on the assembly output, that check isn't optimized away.(The
while let
statement seems to be generating useless function calls for drop as well, btw.)The text was updated successfully, but these errors were encountered: