`indexing_slicing` ignores `match` for length

[eirnym]

Summary

lint ignores context of match slice.len(). Sister of #17398, reported one per lint.

Lint Name

indexing_slicing

Reproducer

I tried this code:

// supported: &[u8] is a function parameter, value from enum variant or provided in any other way
// to compile this code u8 can be replaced with anything implementing Display, or Debug (in that case add `:?` to format string)

match supported.len() {
    0 => {}
    1 => println!("{}", supported[0]),
    _ => println!("{} or {}", supported[0], supported[1]),
}

I saw this happen:

supported[0]
supported[0], supported[1]

indexing may panic

I expected to see this happen:
as `usize is not negative and value 0 was explicitly checked, lint should never fire.

Version

rustc 1.96.0 (ac68faa20 2026-05-25)
binary: rustc
commit-hash: ac68faa20c58cbccd01ee7208bf3b6e93a7d7f96
commit-date: 2026-05-25
host: aarch64-apple-darwin
release: 1.96.0
LLVM version: 22.1.2

Additional Labels

No response

[y21]

Wouldn't this be better written as

match supported {
  [] => {},
  [x] => println!("{}", x),
  [x, y, ..] => println!("{} {}", x, y)
}

anyway (with better binding names)?

Otherwise this issue seems rather arbitrary and I'd expect this to be one of those instances where you just #[allow] the lint. I mean, I think you can always come up with arbitrarily different variants of checking the length and then indexing with a valid index, and I'm not sure it's worth complicating the lint with. The indexing_slicing lint will always have certain "false positives" of this kind and is in the restriction category for that reason

[eirnym]

I agree that specific match would be better (and clippy could propose this refactoring). In the example above indices are guarded by match and a fix could be the same or very similar to #17400

[y21]

In the example above indices are guarded by match and a fix could be the same or very similar to #17400

Yeah but it's still ~100 lines added for one (IMO) hyper-specific case. Should we also avoid warning on

if x.len() == 1 {
  x[0];
}

and

if let 1..=3 = x.len() {
  x[2];
}

and...

I'd definitely expect the first one to be way more common than the one here, and you can come up with many variants of this pattern each complicating the lint more. The lint's purpose is to strictly catch any indexing that may subtly panic at runtime as far as I can tell (with some exceptions that are handled by other lints). It purposefully hasn't really made an attempt at handling obvious patterns where it can't panic, and I like that because the scope of the lint is obvious. If we start recognizing specific patterns, IMO it kinda blurs the scope of the lint because now why not handle all other patterns you can think of.

To be fair, maybe a general solution is possible using a dataflow pass on the MIR or something like that, and handling specific patterns is not so unreasonable for a lint that would be warn-by-default, but again in my view indexing_slicing is meant to be very strict and with limited scope like a lot of other restriction lints that you just are expected to allow a lot of the times where it is fine (since it is in restriction), so I'm really not a fan of hardcoding this particular pattern.

Now, this is my own opinion, I'd be curious to hear what others think (maybe it's controversial!). This general idea of limiting a lint's scope is something I've thought of a lot and would maybe be worth discussing on zulip too.

[eirnym]

Still claim of the assert without a fix is false positive.

[eirnym]

Besides, in your reply you count the data and ignore the fact that code can be reused