Negative trait impls show as "found implementations" in error messages

[scottmcm]

(Spotted in https://users.rust-lang.org/t/the-trait-clone-is-not-implemented-for-mut-t/51989?u=scottmcm)

I tried this code https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=6862c5bd66f1fcdf55fd725a93baffcd:

#[derive(Clone)]
struct Foo<'a, T> {
    x: &'a mut T,
}

Which of course fails to compile, but it gives the following confusing help:

  = help: the following implementations were found:
            <&T as Clone>
            <&mut T as Clone>

The library now has impl<'_, T> !Clone for &'_ mut T, so it looks like this error-generation code path needs to be updated to account for that.

Ideally it'd take advantage of the explicit negative here to say that it's not clone and has been promised that it never will be, but at the very least is shouldn't be showing <&mut T as Clone> which makes it look like it's actually Clone.

cc #68318

[ThePuzzlemaker]

@rustbot claim

[ThePuzzlemaker]

While <&mut T as !Clone> (or just not showing it) makes sense to me, I feel that something like <&mut T as !Clone>, meaning that &mut T can never be Clone would be better to new users.

[ThePuzzlemaker]

Actually, <&mut T as !Clone> would probably not be the best (or easiest to implement afaik) as it's not technically valid syntax, so trying to implement it in the pretty printer, as I originally tried, would break a few things. It'd be better if we either:

• just ignore implementations with negative polarity or
• use impl Trait for Ty syntax e.g. impl<'a> !Clone for &'a mut T and impl<'a> Clone for &'a T for the diagnostic.

[ThePuzzlemaker]

Updating on this: I think that ignoring negative polarity implementations would be the best solution right now (especially as I'm still a new-ish contributor). In the future, it may be helpful to implement something like you suggested, but that would require a lot more changes to the compiler than is feasible for me to do right now.

[ThePuzzlemaker]

I'm going to make some cleanups to my changes, then I'll draft a PR.
Update: looks like my changes caused quite a few tests to fail (which absolutely should not have happened), so I'm trying to re-implement it a different way that should hopefully not do that.

[scottmcm]

@ThePuzzlemaker Splitting it into two changes sounds good to me. Not showing the incorrect one is definitely the higher priority change.

[ThePuzzlemaker]

Turns out some of those test failures actually were correct (as when this bug was introduced, someone must have run x.py test with --bless which unintentionally caused those failures), so I'm going to re-run tests again with my original changes then see which ones are valid (hopefully, all of them). After that, I'll add a regression test.