-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Replace the default branch with an unreachable branch If it is the last variant #120268
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
Changes from all commits
d8b7b5b
08ae838
3d7f8b4
b5bd98d
2884230
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There is no uninhabited enum anywhere in this test... how does the test filename make sense? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This test case came directly from the issue it fixed. It will call There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. But again there's no uninhabited enums anywhere that I can see, so (a) what does the test content have to do with the filename, and (b) what does it have to do with this PR? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Reading the code a bit more, I think the MIR pass (and associated test) are misnamed. This is no longer just about uninhabited variants, it is now also about exploiting that There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. (a) I can change the file name to There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes. I'm considering updating the name. (It’s just that I didn’t think of a suitable name.)
It better for me to have MIR building match the structure of the code itself where possible. (This purpose may not matter either?) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Ah, I may have misunderstood where this optimization kicks in. I thought even this would just use fallback for the last variant: match c {
Less => -5,
Equal => 0,
Greater => 42,
} But already on stable that becomes
Once we have a better name for the pass, it can use that name. (Though it would also be good to mention the issue either in the file name or file contents. It's always good to add more cross-references and those are otherwise much harder to reconstruct in the future.)
I like it. :) The module-level comment in that file should then explain the two ways that "unreachable" is determined. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
This is something This PR transforms following codes match c {
Less => -5,
Equal => 0,
_ => 42,
} to match c {
Less => -5,
Equal => 0,
Greater => 42,
} . |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,24 @@ | ||
//@ compile-flags: -O | ||
|
||
#![crate_type = "lib"] | ||
|
||
#[derive(Clone, Copy, PartialEq, Eq, PartialOrd, Ord)] | ||
pub struct Int(u32); | ||
|
||
const A: Int = Int(201); | ||
const B: Int = Int(270); | ||
const C: Int = Int(153); | ||
|
||
// CHECK-LABEL: @foo( | ||
// CHECK-SAME: [[TMP0:%.*]]) | ||
// CHECK-NEXT: start: | ||
// CHECK-NEXT: [[TMP1:%.*]] = add i32 [[TMP0]], -201 | ||
// CHECK-NEXT: icmp ult i32 [[TMP1]], 70 | ||
// CHECK-NEXT: icmp eq i32 [[TMP0]], 153 | ||
// CHECK-NEXT: [[SPEC_SELECT:%.*]] = or i1 | ||
// CHECK-NEXT: ret i1 [[SPEC_SELECT]] | ||
#[no_mangle] | ||
pub fn foo(x: Int) -> bool { | ||
(x >= A && x <= B) | ||
|| x == C | ||
} |
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 could use a few more comments explaining what happens here -- why all these checks are needed and why they are combined in exactly the way they are. Imagine someone reading this code in a year without knowing about this PR -- what would they have to know to make sense of all this? For instance, what is
check_successors
even checking?Also,
a || b && c
could use parentheses, the precedence is currently unclear.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.
Hmm, testing has started,
r-
or I'll add a PR subsequently?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.
Subsequent PR is fine.