rustc_on_unimplemented should work on specific trait methods

[joshtriplett]

Code

`var_with_complicated_type >= another_var_with_complicated_type`

Current output

implementation for `ComplicatedType < ComplicatedType` and `ComplicatedType > ComplicatedType`

Desired output

implementation for `ComplicatedType >= ComplicatedType`

Rationale and extra context

rustc_on_unimplemented should be applicable to specific trait methods, in addition to the trait as a whole. Then, if the error involves calling a specific trait method, the compiler can give a more specific error message.

In the specific case of PartialOrd, this would also avoid repeating both type names twice.

Other cases

Rust Version

git commit 7349f6b50359fd1f11738765b8deec5ee02d8710

Anything else?

No response

[compiler-errors]

Can you explain your example, perhaps with code? I really have no idea what you're asking for in this issue.

[joshtriplett]

Sure.

Consider code like this:

fn main() {
    if 5 >= String::new() {
        todo!();
    }
}

This produces:

error[E0277]: can't compare `{integer}` with `String`
 --> src/main.rs:2:10
  |
2 |     if 5 >= String::new() {
  |          ^^ no implementation for `{integer} < String` and `{integer} > String`
  |
  = help: the trait `PartialOrd<String>` is not implemented for `{integer}`

This comes from the rustc_on_unimplemented attribute on PartialOrd:

#[rustc_on_unimplemented(
    message = "can't compare `{Self}` with `{Rhs}`",
    label = "no implementation for `{Self} < {Rhs}` and `{Self} > {Rhs}`",
    append_const_msg
)]

I'm suggesting that, in cases like this where the failure comes from a specific operator, we should give a more specific error message, like:

error[E0277]: can't compare `{integer}` with `String`
 --> src/main.rs:2:10
  |
2 |     if 5 >= String::new() {
  |          ^^ no implementation for `{integer} >= String`
  |
  = help: the trait `PartialOrd<String>` is not implemented for `{integer}`

This would be more obviously related to the code the user wrote, and would avoid repeating the two types, which is particularly important when they're large and complex types.

[compiler-errors]

I actually don't think I agree. I just think that label is redundant, and should be removed. Maybe this is useful in a more general case, but I think that label doesn't add much value when it says "can't compare" directly above it.

[joshtriplett]

That works too.