-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Unused loop (break) name gives no compiler warning #50751
Comments
I can mentor this one, though I'll have to look at how the other unused-* lints work before I can provide instructions. Should be an easy task overall though. Addendum: yeah, should be easyish. I'll bang out some mentoring instructions later today when I'm back at a computer if this hasn't been closed as needs-RFC. I think it's fine to implement as-is. |
(READY) Mentoring InstructionsSo all the lints that call out unused elements reside in This lint should be pretty easy, we'll start just like with declare_lint! {
UNUSED_LOOP_LABEL,
Warn,
"warns on unused labels for loops",
}
#[derive(Copy, Clone)]
pub struct UnusedLoopLabel(Vec<Label>);
impl UnusedLoopLabel {
// stateful lints are expected to have a `new()` constructor
pub fn new() -> Self {
UnusedLoopLabel(vec![])
}
}
impl LintPass for UnusedLoopLabel {
fn get_lints(&self) -> LintArray {
lint_array!(UNUSED_LOOP_LABEL)
}
} And then we're going to implement impl EarlyLintPass for UnusedLoopLabel {
fn check_expr(&mut self, _: &EarlyContext, expr: &ast::Expr) {
// match `expr.kind`, looking for any of the loop kinds and pushing their `Label`s to `self.0`
// also look for `Continue` or `Break`, and find/remove their labels from `self.0` in reverse order
// (since loop labels can shadow each other we want to remove the innermost label as that's
// the one that'll be actually used)
// use `label.ident.name` for comparison
}
// called after returning from recursing into nested expressions,
// this is where we emit the lint message
fn check_expr_post(&mut self, ctxt: &EarlyContext, expr: &ast::Expr) {
// look at loop kinds in `expr` again, if that loop's label is in `self.0` then emit a lint message like this:
ctxt.span_lint(UNUSED_LOOP_LABEL, label.ident.span, "unused loop label");
// (make sure to search in reverse order again, and also remove the label from the vec)
}
} Next, add to the following two macro invocations, where it fits alphabetically:
And then you'll implement a UI test by creating //~^ WARN unused loop label Now, run |
@estebank Pfft, nevermind, idents have spans. |
I'd like to take this issue. |
Speaking just for myself, @KyleStach1678, I'd be happy for you to take this. I was just about to fork and start on it, but honestly I don't really have the time to tackle it right now, so I'm glad to hear I might not have to. :-) |
Add lint checks for unused loop labels Previously no warning was generated when a loop label was written out but never used (i.e. in a `break` or `continue` statement): ```rust fn main() { 'unused_label: loop {} } ``` would compile without complaint. This fix introduces `-W unused_loop_label`, which generates the following warning message for the above snippet: ``` warning: unused loop label --> main.rs:2:5 | 2 | 'unused_label: loop {} | ^^^^^^^^^^^^^ | = note: #[warn(unused_loop_label)] on by default ``` Fixes: #50751.
Thanks huge! That was hilariously fast turnaround. Super-impressive. |
I'm confused, though. In the end, the default for unused labels looks like it was changed to allow? The whole point was to have it default to warn… Am I missing something? |
@BartMassey |
Ah, missed that bit, thanks. Who sends that PR? |
@BartMassey if no one was planning to, I could open that PR. Not sure if it would be more appropriate for someone on the lang team to open that up instead though? |
@KyleStach1678 |
See Issue #66324 for an attempt to revive the change to have the lint |
Currently, code like this
is silently accepted. As with unused function parameters or variable declarations, this is usually indicative of a mistake. A warning should be issued unless the break name begins with
_
.Do I need to treat this as a feature request and file an RFC? Please say "no" — the RFC process is heavyweight as hell. I think it's just a bug report 😄.
The text was updated successfully, but these errors were encountered: