False positive in reversed_empty_ranges used with Vec::splice

[dtolnay]

fn main() {
    let mut v = vec![3, 2, 1];
    v.splice(0..0, std::iter::repeat(0).take(4));
    println!("{:?}", v);  // [0, 0, 0, 0, 3, 2, 1]
}

error: this range is empty so it will yield no values
 --> src/main.rs:3:14
  |
3 |     v.splice(0..0, std::iter::repeat(0).take(4));
  |              ^^^^
  |
  = note: `#[deny(clippy::reversed_empty_ranges)]` on by default
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#reversed_empty_ranges

I believe this is a correct use of an empty range.
https://doc.rust-lang.org/std/vec/struct.Vec.html#method.splice

Mentioning @ebroto @yaahc who touched this lint recently in #5583.

---

clippy 0.0.212 (826cb06 2020-06-05)

[ebroto]

Hey @dtolnay, thanks for opening the issue.

So, this is the second issue (the other one being #5628) related to N..N being used intentionally. A quick github search shows that the lint is already being ignored and in most cases it's because of the same pattern, which makes me think that it's more idiomatic that we originally thought.

The original spirit of the lint was to avoid confusion when the developer uses inverted bounds, both the result of the range being empty and a runtime panic in case of indexing a slice. N..N is kind of an edge case, and probably less prone to confusion (and does not panic).

I would be now in favor of not linting N..N, maybe just when used as an argument to a for loop, for backwards compatibility with reverse_range_loop which was superseded by this lint.