new lint: manual_contains

[lapla-cogito]

close #13353

Using contains() for slices are more efficient than using iter().any().

changelog: [manual_contains]: new lint

[rustbot]

r? @Manishearth

rustbot has assigned @Manishearth.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[lapla-cogito]

On second thought, I thought it would be more appropriate to place the lint under the methods directory. Therefore, I am sorry, but I'm going to convert to draft this PR and modify it. now fixed

[samueltardieu]

Don't you mean .contains()? Anyway, I think this is too specific, on my machine it seems to use compiler intrinsics and make no calls to memchr.

You're right about performances though: I benchmarked both .iter().any(==) and .contains() and the latter runs more than 10 times faster on large areas.

[lapla-cogito]

Oh, I had assumed from the implementation that memchr would be used in any environment (including my local environment). Also, this godbolt does so as far as the assembly is concerned: https://rust.godbolt.org/z/Kxrzr81Me

However, if it may differ depending on the environment, the description should be indeed modified, so I'll make a change. Could you please tell me for reference, what's the environment you have checked that?

[samueltardieu]

I think the memchr itself has been replaced by an intrinsic. I'm using the latest nightly compiler on x86_64.

[lapla-cogito]

Thank you! In any case, it looks like this lint description should be modified.

[Manishearth]

I think the memchr() exists for larger integer types too, yes?

[Manishearth]

oh, nope, it doesn't. It could be extended, I think.

[lapla-cogito]

I found that contains() is now faster for certain types (u16, u32, u64, i16, i32, i64, f32, f64, usize, isize) compared to before (see: rust-lang/rust#130991). Therefore, this performance lint should be extended to cover these types starting from Rust 1.84.0 and I'll make a change for this.

[Manishearth]

A thing I'm unsure about is the mixing of two lints like this. I'm going to ask on Zulip if we should be doing two lints here.

https://rust-lang.zulipchat.com/#narrow/channel/257328-clippy/topic/iter.2Eany.28.29.20lint.3A.20one.20or.20two.20lints.3F

[Manishearth]

I'm traveling so I'll wait for @samueltardieu to finish approving

[samueltardieu]

Looks good to me, thanks, approving on my side, provided you fix the latest nit on if/match collapse.

[samueltardieu]

@Manishearth All good for me, hits from lintcheck are legit.

[samueltardieu]

I'm not sure if that requires a FCP given that it has been discussed in Zulip already.

[lapla-cogito]

Rebased.

[lapla-cogito]

Rebased.

[Manishearth]

Thanks for your patience!

[nyurik]

@lapla-cogito thanks for implementing! Two questions:

• would it make sense to catch any non-number cases, i.e. there are a lot of contains() methods, some of which might be a good fit for this method? Technically the restriction should be "anything that implements PartialEq" rather than being a number
• would it handle the macro-expansion variants ok (should there be a test for that?)

[lapla-cogito]

@nyurik

• This lint applies to general slices, meaning non-numeric slices are already covered (this might help clarify why it applies to general slices). There are indeed more cases that use .contains() as you mentioned, and we may add further implementations if there are less efficient ways to write .contains().
• I think so. However, there are currently no tests for such cases. I'll consider adding them if additional test cases seem appropriate. Thanks!

[nyurik]

@lapla-cogito thx for the link! So if I read this right, the general agreement is that we should always promote .contains because it offers better performance guarantees (let alone it is far more idiomatic and easier to read than the iter.any combination). Wouldn't that mean we would want to offer this specific lint to replace any such cases, even if it is not just for the slice?