Skip to content
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

Span is too large for unused rest @ .. pattern warning #81314

Closed
camelid opened this issue Jan 23, 2021 · 5 comments · Fixed by #82655
Closed

Span is too large for unused rest @ .. pattern warning #81314

camelid opened this issue Jan 23, 2021 · 5 comments · Fixed by #82655
Assignees
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-lint Area: Lints (warnings about flaws in source code) such as unused_mut. A-suggestion-diagnostics Area: Suggestions generated by the compiler applied by `cargo fix`. D-invalid-suggestion Diagnostics: A structured suggestion resulting in incorrect code. E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.

Comments

@camelid
Copy link
Member

camelid commented Jan 23, 2021

The compiler suggests replacing rest @ .. with _rest, when in fact it should suggest _rest @ ..:

fn main() {
    let [rest @ ..] = [1, 2, 3];
}

(Playground)

Errors:

   Compiling playground v0.0.1 (/playground)
warning: unused variable: `rest`
 --> src/main.rs:2:10
  |
2 |     let [rest @ ..] = [1, 2, 3];
  |          ^^^^^^^^^ help: if this is intentional, prefix it with an underscore: `_rest`
  |
  = note: `#[warn(unused_variables)]` on by default

warning: 1 warning emitted

    Finished dev [unoptimized + debuginfo] target(s) in 0.73s
     Running `target/debug/playground`

The span should point to just rest.

@camelid camelid added E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. A-lint Area: Lints (warnings about flaws in source code) such as unused_mut. A-diagnostics Area: Messages for errors, warnings, and lints A-suggestion-diagnostics Area: Suggestions generated by the compiler applied by `cargo fix`. D-invalid-suggestion Diagnostics: A structured suggestion resulting in incorrect code. labels Jan 23, 2021
@camelid
Copy link
Member Author

camelid commented Jan 24, 2021

This is where the suggestion is emitted:

self.ir.tcx.struct_span_lint_hir(
lint::builtin::UNUSED_VARIABLES,
first_hir_id,
hir_ids_and_spans.iter().map(|(_, sp)| *sp).collect::<Vec<_>>(),
|lint| {
let mut err = lint.build(&format!("unused variable: `{}`", name));
let (shorthands, non_shorthands): (Vec<_>, Vec<_>) =
hir_ids_and_spans.into_iter().partition(|(hir_id, span)| {
let var = self.variable(*hir_id, *span);
self.ir.variable_is_shorthand(var)
});
let mut shorthands = shorthands
.into_iter()
.map(|(_, span)| (span, format!("{}: _", name)))
.collect::<Vec<_>>();
// If we have both shorthand and non-shorthand, prefer the "try ignoring
// the field" message, and suggest `_` for the non-shorthands. If we only
// have non-shorthand, then prefix with an underscore instead.
if !shorthands.is_empty() {
shorthands.extend(
non_shorthands
.into_iter()
.map(|(_, span)| (span, "_".to_string()))
.collect::<Vec<_>>(),
);
err.multipart_suggestion(
"try ignoring the field",
shorthands,
Applicability::MachineApplicable,
);
} else {
err.multipart_suggestion(
"if this is intentional, prefix it with an underscore",
non_shorthands
.into_iter()
.map(|(_, span)| (span, format!("_{}", name)))
.collect::<Vec<_>>(),
Applicability::MachineApplicable,
);
}
err.emit()
},
);

However, I think the issue is in the hir_ids_and_spans argument. That argument is passed in here:

for (_, (ln, var, hir_ids_and_spans)) in vars {
if self.used_on_entry(ln, var) {
let id = hir_ids_and_spans[0].0;
let spans = hir_ids_and_spans.into_iter().map(|(_, sp)| sp).collect();
on_used_on_entry(spans, id, ln, var);
} else {
self.report_unused(hir_ids_and_spans, ln, var);
}
}

You might have to hunt around a bit to find the spot where the spans are created.

@camelid
Copy link
Member Author

camelid commented Jan 24, 2021

Feel free to ask in #t-compiler/help on Zulip if you have any questions! You may also want to look through the rustc-dev-guide.

@estebank
Copy link
Contributor

For working on this you won't need stage 2, stage 1 will suffice.

@sladyn98
Copy link
Contributor

I guess I can give this issue a shot I have the setup ready and stage one works fine. I am new to rust so forgive me for asking too many questions

@SkiFire13
Copy link
Contributor

Since it has been more than 2 weeks since the last update I guess this is free to pick? In case someone is still working on this let me know

@rustbot claim

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-lint Area: Lints (warnings about flaws in source code) such as unused_mut. A-suggestion-diagnostics Area: Suggestions generated by the compiler applied by `cargo fix`. D-invalid-suggestion Diagnostics: A structured suggestion resulting in incorrect code. E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants