"Unused variable" warning gives incorrect suggestion when binding fields of struct-like variants

[elidupree]

Here's a short example:

enum Enum {
  Variant {field: u32},
  OtherVariant,
}

fn main() {
  let whatever = Enum::Variant{field:0};
  if let Enum::Variant {field} = whatever {
    // field left unused
  }
}

This produces the warning:

warning: unused variable: `field`
 --> src/main.rs:8:25
  |
8 |   if let Enum::Variant {field} = whatever {
  |                         ^^^^^
  |
  = note: #[warn(unused_variables)] on by default
  = note: to avoid this warning, consider using `_field` instead

But changing it to _field is an error because that's not the name of the field. The warning should probably suggest to use Enum::Variant {..} instead.

This also occurs in explicit match statements and irrefutable let patterns – probably anywhere you can bind a field of a struct-like variant.

[estebank]

The code to do so needs to account for cases where .. is already being used, and while at it probably collect multiple unused variables in the same struct in the same diagnostic:

warning: unused variables: `field` & `field2`
 --> src/main.rs:8:25
  |
8 |   if let Enum::Variant {field, field2, field3} = whatever {
  |                         ^^^^^  ^^^^^^
  |
  = note: #[warn(unused_variables)] on by default
  = help: to avoid this warning, consider using `..` instead:
  |
8 |   if let Enum::Variant {field3, ..} = whatever {
  |                         ^^^^^^^^^^

instead of

warning: unused variable: `field`
 --> src/main.rs:8:25
  |
8 |   if let Enum::Variant {field, field2, field3} = whatever {
  |                         ^^^^^
  |
  = note: #[warn(unused_variables)] on by default
  = note: to avoid this warning, consider using `_field` instead

warning: unused variable: `field2`
 --> src/main.rs:8:32
  |
8 |   if let Enum::Variant {field, field2, field3} = whatever {
  |                                ^^^^^^
  |
  = note: to avoid this warning, consider using `_field2` instead

In the suggestion there're four cases: we need to add .. because the struct list would end up empty, remove all the unused fields from the list and add , .. because the list is not empty, only remove the unused fields, because the , .. is already there, or replace everything with .. if , .. is already there and the list ends up empty.

[daboross]

Just an idea: what about suggesting field2: _ instead? This keeps the behavior of needing to handle new fields but still ignores the specific field value.

[oli-obk]

Already reported in #46866

[Mark-Simulacrum]

Closed #46866 in favor of this as it had less discussion.

[estebank]

Just an idea: what about suggesting field2: _ instead? This keeps the behavior of needing to handle new fields but still ignores the specific field value.

I prefer the output I stated, mainly because it could introduce the concept to people, but if somebody implements that suggestion instead, I would gladly accept it. It might be even better if we suggested both alternatives, but that might be too noisy.

[zackmdavis]

In the suggestion there're four cases [...]

This would be nontrivial (although probably not difficult) to implement compared to the fieldname: _ suggestions (about which, PR forthcoming), because the liveness checker currently doesn't bother remembering which local variables were created in the same pattern.