assigning_clones causes infinite recursion when it triggers inside a clone_from() impl

[matthiaskrgr]

Summary

maybe we should skip everything that is either self or anything that is inside a impl of fn clone_from()?
cc @Kobzol @blyxyas @kpreid

Reproducer

I tried this code:

impl<V: Clone> Clone for MaybeReachable<V> {
    fn clone(&self) -> Self {
        match self {
            MaybeReachable::Reachable(x) => MaybeReachable::Reachable(x.clone()),
            MaybeReachable::Unreachable => MaybeReachable::Unreachable,
        }
    }

    fn clone_from(&mut self, source: &Self) {
        match (&mut *self, source) {
            (MaybeReachable::Reachable(x), MaybeReachable::Reachable(y)) => {
                x.clone_from(y);
            }
            //_ => *self = source.clone(), // original
            _ => self.clone_from(source), // BOOM
        }
    }
}

I expected to see this happen:

Instead, this happened:

Version

rustc 1.79.0-nightly (ef4936510 2024-03-30)
binary: rustc
commit-hash: ef493651025db2d5c38225c12ef97fd832c00c4a
commit-date: 2024-03-30
host: x86_64-unknown-linux-gnu
release: 1.79.0-nightly
LLVM version: 18.1.2

Additional Labels

No response

[Kobzol]

Yeah that's a good point, we shouldn't fire the lint inside actual Clone implementation. I'll try to fix it.

[matthiaskrgr]

I saw this happen a couple times in core and didn't think much of it as it is not an uncommon pattern, for i.e. the "filter_map" lint to trigger inside the actual "fn filter_map()" as inside that function, we have to use the "manual" pattern for obvious reasons...

I'm wondering if there is a more general way to fix this, like "if we know we are going to suggest replacing code with a fn X(a,b) -> y, do bail out if the code we are checking is inside a function that matches that signature.

[blyxyas]

Currently the lint is set to applicability Unspecified, so this shouldn't be an issue. I was thinking "it would be great if we didn't lint for the definition in the compiler" but then I thought "why is Clippy being run in the compiler lol"

[matthiaskrgr]

why is Clippy being run in the compiler lol

I've been doing this since more than 4 years 🤷

Now I can see that "impl inside libstd/libcore" is a bit of an edge case, however in this case it would also trigger for types that were declared inside the compiler, so this might aswell be a type inside your everyday rust crate that implements Clone and clonefrom.