Repository: rust
Issue: Varying diagnostics for multiplying Option<i32> and u32/i32, depending on how the call is written
Labels: A-diagnostics,T-compiler

### Code

```Rust
// https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=8432adbd1c12bd8e71fd388725efaf45

use std::ops::Mul;
fn main() {

    // This should suggest expect
    // Stable (1.73.0):     No help             Bad
    // Nightly (1.75.0-n):  No help             Bad
    let abs = 7i32.checked_abs();
    let answer = abs * 5u32; // Case 1

    // This should suggest expect
    // Stable (1.73.0):     Others implement trait `Mul<Rhs>    Bad
    // Nightly (1.75.0-n):  Others implement trait `Mul<Rhs>    Bad
    let abs_2 = 7i32.checked_abs();
    let answer_2 = 5u32 * abs_2; // Case 2

    // This should suggest expect
    // Stable (1.73.0):     Suggested expect    Good :)
    // Nightly (1.75.0-n):  Suggested expect    Good :)
    let abs_3 = 8i32.checked_abs();
    let answer_3 = abs_3.mul(3); // Case 3

    // This should suggest expect
    // Stable (1.73.0):     Others implement trait `Mul<Rhs>    Bad
    // Nightly (1.75.0-n):  Others implement trait `Mul<Rhs>    Bad
    let abs_4 = 9i32.checked_abs();
    let answer_4 = 9i32.mul(abs_4); // Case 4
}
```


### Current output

```Shell
Compiling playground v0.0.1 (/playground)
error[E0369]: cannot multiply `Option<i32>` by `u32`
 --> src/main.rs:8:22
  |
8 |     let answer = abs * 5u32; // Case 1
  |                  --- ^ ---- u32
  |                  |
  |                  Option<i32>

error[E0277]: cannot multiply `u32` by `Option<i32>`
  --> src/main.rs:14:25
   |
14 |     let answer_2 = 5u32 * abs_2; // Case 2
   |                         ^ no implementation for `u32 * Option<i32>`
   |
   = help: the trait `Mul<Option<i32>>` is not implemented for `u32`
   = help: the following other types implement trait `Mul<Rhs>`:
             <u32 as Mul>
             <u32 as Mul<Duration>>
             <u32 as Mul<&u32>>
             <&'a u32 as Mul<u32>>
             <&u32 as Mul<&u32>>

error[E0599]: no method named `mul` found for enum `Option` in the current scope
  --> src/main.rs:20:26
   |
20 |     let answer_3 = abs_3.mul(3); // Case 3
   |                          ^^^ method not found in `Option<i32>`
   |
note: the method `mul` exists on the type `i32`
  --> /rustc/189d6c71f3bb6c52113b5639a80839791974fd22/library/core/src/ops/arith.rs:328:5
help: consider using `Option::expect` to unwrap the `i32` value, panicking if the value is an `Option::None`
   |
20 |     let answer_3 = abs_3.expect("REASON").mul(3); // Case 3
   |                         +++++++++++++++++

error[E0277]: cannot multiply `i32` by `Option<i32>`
  --> src/main.rs:26:29
   |
26 |     let answer_4 = 9i32.mul(abs_4); // Case 4
   |                         --- ^^^^^ no implementation for `i32 * Option<i32>`
   |                         |
   |                         required by a bound introduced by this call
   |
   = help: the trait `Mul<Option<i32>>` is not implemented for `i32`
   = help: the following other types implement trait `Mul<Rhs>`:
             <i32 as Mul>
             <i32 as Mul<&i32>>
             <&'a i32 as Mul<i32>>
             <&i32 as Mul<&i32>>

Some errors have detailed explanations: E0277, E0369, E0599.
For more information about an error, try `rustc --explain E0277`.
error: could not compile `playground` (bin "playground") due to 4 previous errors
```


### Desired output

In an ideal world, I would expect the same help for each line - probably a suggest to expect the Option.

Some operators clearly are not commutative, but I would have thought `*` was. I've used it instead of `+` to avoid `did you mean .and()` clutter but it's the same result there as well.

Given similar code is generated for the operator and the method call (I don't know what the exact code the operator generates is checked/unchecked wise) naively one would expect a similar set of help generated.

I can see why the compiler has more information when the LHS type is concrete, but it's a bit unfortunate.


### Rationale and extra context

[Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=8432adbd1c12bd8e71fd388725efaf45)

### Other cases

_No response_

### Anything else?

_No response_