Calling `.get_ref()` on a tuple or tuple struct suggests pinning it

[ginnyTheCat]

Code

use std::{fs::File, io::BufReader};

struct F(BufReader<File>);

fn main() {
    let f = F(BufReader::new(File::open("x").unwrap()));

    let x = f.get_ref();
}

Current output

error[E0599]: no method named `get_ref` found for struct `F` in the current scope
 --> src/main.rs:8:15
  |
3 | struct F(BufReader<File>);
  | -------- method `get_ref` not found for this struct
...
8 |     let x = f.get_ref();
  |               ^^^^^^^ method not found in `F`
  |
help: one of the expressions' fields has a method of the same name
  |
8 |     let x = f.0.get_ref();
  |               ++
help: consider pinning the expression
  |
8 ~     let mut pinned = std::pin::pin!(f);
9 ~     let x = pinned.as_ref().get_ref();
  |

Desired output

error[E0599]: no method named `get_ref` found for struct `F` in the current scope
 --> src/main.rs:8:15
  |
3 | struct F(BufReader<File>);
  | -------- method `get_ref` not found for this struct
...
8 |     let x = f.get_ref();
  |               ^^^^^^^ method not found in `F`
  |
help: one of the expressions' fields has a method of the same name
  |
8 |     let x = f.0.get_ref();
  |               ++
  |

Rationale and extra context

I'm not quite sure why it recommends pinning it and then directly derefing it again. Moving from a tuple struct to a tuple even removes the .0 suggestion (see output below).

Other cases

error[E0599]: no method named `get_ref` found for tuple `(BufReader<File>,)` in the current scope
 --> src/main.rs:8:15
  |
8 |     let x = f.get_ref();
  |               ^^^^^^^ method not found in `(BufReader<File>,)`
  |
help: consider pinning the expression
  |
8 ~     let mut pinned = std::pin::pin!(f);
9 ~     let x = pinned.as_ref().get_ref();
  |

Rust Version

rustc 1.90.0-nightly (f8e355c23 2025-07-27)
binary: rustc
commit-hash: f8e355c230c6eb7b78ffce6a92fd81f78c890524
commit-date: 2025-07-27
host: x86_64-unknown-linux-gnu
release: 1.90.0-nightly
LLVM version: 20.1.8

Anything else?

No response

[estebank]

The logic in suggest_traits_to_import looks for the method not found in a few alternative receiver types, including Pin<&T> when T::method isn't found. The reason the suggestion is given, is because Pin::as_ref exists, so the suggestion is technically valid, but it doesn't really help the end user in most cases.