Use MIR body to identify more "default equivalent" calls for derivable_impls

[estebank]

When looking for Default impls that could be derived, we look at the body of their fn default() and if it is an fn call or literal we check if they are equivalent to what #[derive(Default)] would have used.

Now, when checking those fn calls in the fn default() body, we also compare against the corresponding type's Default::default body to see if our call is equivalent to that one.

For example, given

struct S;

impl S {
    fn new() -> S { S }
}

impl Default for S {
    fn default() -> S { S::new() }
}

<S as Default>::default() and S::new() are considered equivalent. Given that, if the user also writes

struct R {
    s: S,
}

impl Default for R {
    fn default() -> R {
        R { s: S::new() }
    }
}

the derivable_impls lint will now trigger.

changelog: [derivable_impls]: detect when a Default impl is using the same fn call that that type's Default::default calls
changelog: [mem_replace_with_default]: detect when std::mem::replace is being called with the same fn that that type's Default::default calls, without the need of a manually maintained list

[rustbot]

r? @Jarcho

rustbot has assigned @Jarcho.
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

[samueltardieu]

Very interesting.

In particular, your change also affects mem_replace_with_default, see the lintcheck run. If those suggestions are valid (and it looks like they are), you should add tests to tests/ui/mem_replace.rs as well to reflect this and make sure we don't regress later.

[Jarcho]

Sorry for the long delay. Just one question, otherwise this looks good.

[Jarcho]

I know there are cases where the MIR isn't available, but what does rustdoc have to do with clippy here?

[estebank]

I believe that this might have been a comment from when I implemented this in rustc itself, which triggered an ICE when invoked by rustdoc. The check I think is still good to keep, but maybe not the comment?

[Jarcho]

We use impossible_predicates in other places to cover when optimized_mir fails, but is_mir_available seems like it's the better thing to use.