Complexity lint against `some_string[0..some_len].len()`

What it does

I apologize if this comes across as confusing - I'm not entirely sure how to word it.

This lint would look for instances where the user is getting a slice of a string, with the starting point of the range being 0, and then calling len() on that slice.

The reason I believe this works is because impl SliceIndex<str> for Range<usize> states the following:

Returns a slice of the given string from the byte range [begin, end).

This means that, if you're getting a string slice from 0 to some_var, some_var will already need to be a length in bytes. Thus, some_string[0..some_calculated_len] will always be some_calculated_len bytes long. And thus, some_string[0..some_calculated_len].len() will always be the same as just some_calculated_len.

Advantage

Less complex-looking code, while still functioning the same.

Drawbacks

None that I'm aware of - the code should function exactly the same afterwards.

Example

let len_in_bytes = some_string[0..the_len_we_want].len();

Could be written as:

let len_in_bytes = the_len_we_want;

Start by reading the linked Rust SliceIndex for Range documentation and inspecting how Clippy represents complexity lints. Done means the proposed pattern is recognized safely and covered by appropriate lint tests, with the issue's example producing the simpler equivalent.