Clippy lint · Restriction · checked with Clippy 0.1.99

clippy::missing_asserts_for_indexing: indexing into a slice multiple times without an `assert`

What it meansChecks for repeated slice indexing without asserting beforehand that the length is greater than the largest index used to index into the slice. It is in the restriction group and off by default.

What you see

warning: indexing into a slice multiple times without an `assert`
 --> main.rs:5:5
  |
5 |     v[0] + v[1] + v[2] + v[3]
  |     ^^^^   ^^^^   ^^^^   ^^^^
  |
  = help: consider asserting the length before indexing: `assert!(v.len() > 3);`
  = note: asserting the length before indexing will elide bounds checks
  = help: for further information visit https://rust-lang.github.io/rust-clippy/stable/index.html#missing_asserts_for_indexing
  = note: requested on the command line with `-W clippy::missing-asserts-for-indexing`

Real output of Clippy 0.1.99 (Rust 1.99) on the example below. Names and line numbers in yours will differ.

Does it matter?

In the general case where the compiler does not have a lot of information about the length of a slice, indexing it repeatedly will generate a bounds check for every single index. Asserting that the length of the slice is at least as large as the largest value to index beforehand gives the compiler enough information to elide the bounds checks, effectively reducing the number of bounds checks from however many times the slice was indexed to just one (the assert).

Lints that forbid language features for specific codebases (no unwrap, no indexing...). Off by default; pick them one by one, never the whole group.

How to fix it

Clippy can fix this one for you: run cargo clippy --fix (add --allow-dirty if you have uncommitted changes). Review the diff before you commit.

Flagged

fn sum(v: &[u8]) -> u8 {
    // 4 bounds checks
    v[0] + v[1] + v[2] + v[3]
}

Write this instead

fn sum(v: &[u8]) -> u8 {
    assert!(v.len() > 3);
    // no bounds checks
    v[0] + v[1] + v[2] + v[3]
}

Turn it off, or on

It is off by default. To use it, set it to warn or deny:

Whole crate (Cargo.toml)

[lints.clippy]
missing_asserts_for_indexing = "warn"

In code

#![warn(clippy::missing_asserts_for_indexing)]

One run

cargo clippy -- -W clippy::missing-asserts-for-indexing

The [lints] table needs Rust 1.74 or newer. In a workspace, put it under [workspace.lints.clippy] and add [lints] workspace = true to each member.

Restrictiongroup

allowdefault level

yesfixed by cargo clippy --fix

1.74.0added in Rust

Clippy's own documentation

What it does

Checks for repeated slice indexing without asserting beforehand that the length is greater than the largest index used to index into the slice.

Why restrict this?

In the general case where the compiler does not have a lot of information about the length of a slice, indexing it repeatedly will generate a bounds check for every single index.

Asserting that the length of the slice is at least as large as the largest value to index beforehand gives the compiler enough information to elide the bounds checks, effectively reducing the number of bounds checks from however many times the slice was indexed to just one (the assert).

Drawbacks

False positives. It is, in general, very difficult to predict how well the optimizer will be able to elide bounds checks and it very much depends on the surrounding code. For example, indexing into the slice yielded by the slice::chunks_exact iterator will likely have all of the bounds checks elided even without an assert if the chunk_size is a constant.

Asserts are not tracked across function calls. Asserting the length of a slice in a different function likely gives the optimizer enough information about the length of a slice, but this lint will not detect that.

Example

fn sum(v: &[u8]) -> u8 {
    // 4 bounds checks
    v[0] + v[1] + v[2] + v[3]
}

Use instead:

fn sum(v: &[u8]) -> u8 {
    assert!(v.len() > 3);
    // no bounds checks
    v[0] + v[1] + v[2] + v[3]
}

From the Clippy lint list (0.1.99), part of the Rust project, MIT or Apache-2.0. Official entry.

Up next

Also worth your time

Did this answer your question?