Confusing error when implementing a trait over a reference and incorrectly using &self as parameter

[qsantos]

Code

struct S {}
trait Trait { fn f(self); }
impl Trait for &S {
    fn f(&self) { }
}

Current output

error[E0053]: method `f` has an incompatible type for trait
 --> src/lib.rs:4:10
  |
4 |     fn f(&self) { }
  |          ^^^^^
  |          |
  |          expected `S`, found `&S`
  |          help: change the self-receiver type to match the trait: `self`
  |
note: type in trait
 --> src/lib.rs:2:20
  |
2 | trait Trait { fn f(self); }
  |                    ^^^^
  = note: expected signature `fn(&S)`
             found signature `fn(&&S)`

For more information about this error, try `rustc --explain E0053`.

Desired output

error[E0053]: method `f` has an incompatible type for trait
 --> src/lib.rs:4:10
  |
4 |     fn f(&self) { }
  |          ^^^^^
  |          |
  |          expected `&S`, found `&&S`
  |          help: change the self-receiver type to match the trait: `self`
  |
note: type in trait
 --> src/lib.rs:2:20
  |
2 | trait Trait { fn f(self); }
  |                    ^^^^
  = note: expected signature `fn(&S)`
             found signature `fn(&&S)`

For more information about this error, try `rustc --explain E0053`.

Rationale and extra context

I found this specific part of the message confusing:

8 |     fn f(&self) {
  |          ^^^^^
  |          |
  |          expected `S`, found `&S`

I would expect it to say either:

8 |     fn f(&self) {
  |          ^^^^^
  |          |
  |          expected `&S`, found `&&S`

or:

8 |     fn f(&self) {
  |           ^^^^
  |           |
  |           expected `S`, found `&S`

Note that the error message is the exact same (but not the note) with this other example:

struct S {}
trait Trait { fn f(self); }
impl Trait for S {
    fn f(&self) { }
}

Of course, I might misinterpret how this message should be read. In any case, the attached note is perfectly clear, so this is a minor issue.

Other cases

No response

Anything else?

No response

[JasonJ2021]

rust/compiler/rustc_hir_analysis/src/check/compare_impl_item.rs

Lines 298 to 305 in e55544c

	// FIXME: We'd want to keep more accurate spans than "the method signature" when
	// processing the comparison between the trait and impl fn, but we sadly lose them
	// and point at the whole signature when a trait bound or specific input or output
	// type would be more appropriate. In other places we have a `Vec<Span>`
	// corresponding to their `Vec<Predicate>`, but we don't have that here.
	// Fixing this would improve the output of test `issue-83765.rs`.
	let result = ocx.sup(&cause, param_env, trait_sig, impl_sig);

Type checker compares the trait signature and impl signature structurally (i.e., cmp &S, &&S -> cmp S, &S). Due to the loss of spans, the compiler can only report inner TypeError with an inaccurate span, which points to the entire signature.
You can find the structually relating function below

rust/compiler/rustc_middle/src/ty/relate.rs

Lines 406 to 417 in e55544c

	/// Relates `a` and `b` structurally, calling the relation for all nested values.
	/// Any semantic equality, e.g. of projections, and inference variables have to be
	/// handled by the caller.
	#[instrument(level = "trace", skip(relation), ret)]
	pub fn structurally_relate_tys<'tcx, R: TypeRelation<'tcx>>(
	relation: &mut R,
	a: Ty<'tcx>,
	b: Ty<'tcx>,
	) -> RelateResult<'tcx, Ty<'tcx>> {
	let tcx = relation.tcx();
	match (a.kind(), b.kind()) {
	(&ty::Infer(_), _) | (_, &ty::Infer(_)) => {