Suggest `size_of_val(a)` for `a.len() * size_of::<T>()`

[scottmcm]

What it does

When a is &[T], detect a.len() * size_of::<T>() and suggest size_of_val(a) instead.

Lint Name

manual_slice_size_calculation

Category

complexity, perf

Advantage

• Shorter to write
• Removes the need for the human and the compiler to worry about overflow in the multiplication
• Potentially faster at runtime as rust emits special no-wrapping flags when it calculates the byte length
• Less turbofishing

Drawbacks

No response

Example

https://github.com/rust-lang/rust/blob/13afbdaa0655dda23d7129e59ac48f1ec88b2084/library/core/src/hash/mod.rs#L837

let newlen = data.len() * mem::size_of::<$ty>();

Could be written as:

let newlen = mem::size_of_val(data);

[schubart]

@rustbot claim

[asquared31415]

slice.len(), usize multiplication, and size_of::<T> are all const, but size_of_val is only unstably const. Code may be using this pattern out of necessity.

[blyxyas]

size_of_val is only unstably const.

Then maybe only linting for nightly builds? It can be quickly checked from cx.sess().is_nightly_build(). As far as I'm aware, there are no unstable Clippy lints.

[Alexendoo]

It can still lint on stable, but only outside of const contexts which can be checked using in_constant