-
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
Make broken MIR a proper lint. #119260
base: master
Are you sure you want to change the base?
Make broken MIR a proper lint. #119260
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -3933,6 +3933,15 @@ declare_lint! { | |
"`break` expression with label and unlabeled loop as value expression" | ||
} | ||
|
||
crate::declare_tool_lint! { | ||
/// The `broken_mir` statically detects undefined behaviour in the MIR optimization pipeline. | ||
/// This is an internal lint, and not intended to be used directly. | ||
pub rustc::BROKEN_MIR, | ||
Deny, | ||
"broken MIR", | ||
report_in_external_macro: true | ||
} | ||
Comment on lines
+3936
to
+3943
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. Bike-shedding: The term broken MIR is already used when validation fails. It also overstates the severity of what is being reported. Maybe unusual MIR? 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. I do believe broken is the right term here 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. In what sense is this MIR broken? The motivation behind moving those checks out of validator was the fact that there is nothing inherently wrong about violating them. Those reports should NOT be treated as bugs. It doesn't even mean that the user provided program has an undefined behaviour, since we don't know whether those instructions are ever executed. |
||
|
||
declare_lint! { | ||
/// The `non_exhaustive_omitted_patterns` lint aims to help consumers of a `#[non_exhaustive]` | ||
/// struct or enum who want to match all of its fields/variants explicitly. | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -21,6 +21,7 @@ fn multiple_storage() { | |
{ | ||
StorageLive(a); | ||
StorageLive(a); | ||
//~^ ERROR broken MIR | ||
Return() | ||
} | ||
} | ||
|
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.
Forbid maybe?
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.
One use case is to use
expect
. And you cannot expect a forbidden lint.