Fix suggestion for mutability mismatch between trait def and trait impl in 2051 edition

[GuillaumeGomez]

This code:

mod bar {
    pub struct X;
}

pub trait A {
    fn f(x: &mut bar::X);
}

mod b {
    pub struct X;

    impl crate::A for X {
        fn f(_x: &crate::bar::X) {}
    }
}

emits:

error[E0053]: method `f` has an incompatible type for trait
  --> foo.rs:13:18
   |
13 |         fn f(_x: &crate::bar::X) {}
   |                  ^^^^^^^^^^^^^^ types differ in mutability
   |
note: type in trait
  --> foo.rs:6:13
   |
 6 |     fn f(x: &mut bar::X);
   |             ^^^^^^^^^^^
   = note: expected signature `fn(&mut X)`
              found signature `fn(&X)`
help: change the parameter type to match the trait
   |
13 -         fn f(_x: &crate::bar::X) {}
13 +         fn f(_x: &mut bar::X) {}
   |

Which is wrong. This PR fixes it. However the Ty doesn't hold a context (or at least not a correct one) allowing to have a correct path to the X type. So instead, in case of a mutability mismatch, we (try to) retrieve the code snippet, and remove/add the mut keyword. If we fail to, we revert to the current behaviour.

r? @mejrs

[mejrs]

(for context: #t-compiler/help > Wrong Ty "scope"(?) in suggestion @ 💬)

It looks like the real problem here is there's no functionality (or we're unaware of it) for "what is the proper path to item X to use it in scope Y". Can you find or create something like that rather than have all of this just to support one case of a type error?

View changes since this review

[GuillaumeGomez]

It looks like the real problem here is there's no functionality (or we're unaware of it) for "what is the proper path to item X to use it in scope Y". Can you find or create something like that rather than have all of this just to support one case of a type error?

Agreed, the solution I came up with is not satisfying. So I'd love to create this new API, but I will likely need some help.

[mejrs]

I think with_crate_prefix should work for this? Or with_resolve_crate_name? I haven't looked deeply in what they do but they look like what we want. But I'm unsure it's correct on the 2015 edition.

[GuillaumeGomez]

With rustc_middle::ty::print::with_resolve_crate_name!(trait_ty):

&mut bar::X

With rustc_middle::ty::print::with_crate_prefix!(trait_ty):

&mut bar::X

And with rustc_middle::ty::print::with_crate_prefix!(rustc_middle::ty::print::with_resolve_crate_name!(trait_ty)):

&mut bar::X

So unless I wrote invalid code, I'll instead tweak how we display Ty directly, going through Adt if there is one, otherwise leaving the current output.

[GuillaumeGomez]

Ok I'm a moron. And I'll rewrite these macros because it made me loss way too much time.

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[GuillaumeGomez]

Updated. The fix was actually to allow the 2015 edition to have paths prepended with crate::.