single_match: Don't lint non-exhaustive matches; support tuples by jubnzv · Pull...

This puzzles me. Why don't we know at which argument #no is the ..? And why do we need the span for this? It seems like a very roundabout way to implement this.

The point is that we don't know the actual number of the patterns replaced by ...

For example:

match (Some(E::V), Some(E::V), Some(E::V), Some(E::V)) {
  (Some(E::V), .., None) => todo!(), // `..` replaces [1, 2]
  (.., None) => todo!(), // `..` replaces [0, 1, 2]
}

We want to iterate to the both arms at the same time, to make sure that the elements with the same index form the exhaustive match. So, the logic implemented here basically evaluates the maximum possible length of the patterns and traverses both arms, considering entries in .. as wildcards (_).

Probably, the most simple solution would be to run the lint iff the second arm contains only wildcards. But this will make the lint a bit less accurate, because we won't be able to generate warnings in some cases.

In that case shouldn't, position- and rpositioning the .. pattern in the subpatterns be enough? Also "span" has a different meaning in most lints, so the naming could be improved (if needed at all).

I fixed the naming to make it differ from rustc's Spans.

I'm not sure if we want to remove these variables at all, because this would complicate the loop in places when we need to evaluate the relative offset from the current pattern to the .. position.