explicit_auto_deref suggests code that does not compile

[rossmacarthur]

Summary

Reproducer attached. Clippy suggests to remove the dereference operator but without it the code doesn't compile.

Lint Name

explicit_auto_deref

Reproducer

I tried this code:

fn takes_array_ref<T, const N: usize>(array: &&[T; N]) {
    takes_slice(*array) // clippy suggests to remove dereference
}

fn takes_slice<T>(slice: &[T]) {
    todo!()
}

I saw this happen:

 --> src/lib.rs:2:17
  |
2 |     takes_slice(*array)
  |                 ^^^^^^ help: try this: `array`
  |
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#explicit_auto_deref
  = note: `#[warn(clippy::explicit_auto_deref)]` on by default

I expected to see this happen:
No lint, or a suggestion that builds

Version

rustc 1.67.0-nightly (6284998a2 2022-11-12)
binary: rustc
commit-hash: 6284998a2677d7e3e8420db783f3aa4fd80d7423
commit-date: 2022-11-12
host: aarch64-apple-darwin
release: 1.67.0-nightly
LLVM version: 15.0.4

Additional Labels

@rustbot label +I-suggestion-causes-error

[samuelpilz]

I ran into a similar issue, did some investigating and found a different minified example that might help in understanding the problem more. I even got a full matrix of [true/false] [positives/negatives]. Apparently, function calls with explicit and inferred type parameters need to be handled differently.

playground

fn x<T: Copy>() -> impl Fn(T) {
    |_| ()
}

fn y<T: Copy>(_: T) {}

pub fn examples(input: &mut &str) {
    // in all cases: T=&str (`&mut &str` is not `Copy`)

    // reported. false positive
    x()(*input);
    // this fails to compile
    // x()(input);

    // reported. true positive
    x::<&str>()(*input);
    // this fix compiles
    x::<&str>()(input);

    // not reported. true neagtive
    y(*input);
    // this fails to compile
    // y(input);

    // not reported. false negative
    y::<&str>(*input);
    // this compiles
    y::<&str>(input);
}

[wr7]

I've looked into this issue a bit, and I believe that the comment above illustrates a completely different (but still important) issue.

This whole array issue probably stems from the fact that [T; N] does not implement Deref<Target = [T]>, so it needs to be handled specially, and the special handling is different between rustc and clippy.

PR #12976 addresses this issue and it fixes the original code, but, at the time of writing this, it doesn't correctly handle more than 2 refs/derefs (such as the following):

pub fn takes_array_ref<T, const N: usize>(array: &&&[T; N]) {
    takes_slice(**array) // clippy still suggests to remove both dereferences
}

pub fn takes_slice<T>(_slice: &[T]) {
    todo!()
}