fix(map_clone): avoid suggestions after type-changing coercions

[saberoueslati]

map_clone incorrectly suggests .cloned() for calls such as:

input.iter().map(|s: &&String| String::clone(s))

Here, String::clone coerces &&String to &String and returns String, while .cloned() returns &String.

Only lint when argument adjustments preserve its type. This fixes the false positive while retaining valid Option and Result diagnostics. Tests cover String::clone and <String as Clone>::clone.

Fixes #17550

changelog: Fix [map_clone] false positive for clone calls using deref coercion

[rustbot]

Thanks for the pull request. A reviewer will take a look after it receives 2 community reviews.

In the meantime, we would highly appreciate if you could try to review any of PRs waiting on community reviews.

[CommanderStorm]

Community review: Change LGTM

Could you test if this change also fixes this FP and add it to the description if it does?

• #10278

View changes since this review

[saberoueslati]

@CommanderStorm
I checked #10278. This change doesn't affect that case: its reproducer uses method-call syntax (s.clone()), while this PR only changes the function-call path (String::clone(s)).
I also don't think it is a false positive. The suggested .cloned() replacement compiles and still produces a Vec<String>. The compilation error in the issue comes from applying .clone() instead of the suggested .cloned(), as Alexendoo pointed out in the first comment. The equivalent case is already covered as an intended lint in tests/ui/map_clone.rs:14, and the test passes.

[rustbot]

r? @llogiq

rustbot has assigned @llogiq for the project review.
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

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: 9 candidates
• 9 candidates expanded to 9 candidates
• Random selection from 6 candidates