When annotations needed, look at impls for more accurate suggestions

[estebank]

When encountering an expression that needs type annotations, if we have the trait DefId we look for all the impls that could be satisfied by the expression we have (without looking at additional obligations) and suggest the fully qualified to specific impls. For left over type parameters, we replace them with _.

error[E0283]: type annotations needed
  --> $DIR/E0283.rs:35:24
   |
LL |     let bar = foo_impl.into() * 1u32;
   |                        ^^^^
   |
note: multiple `impl`s satisfying `Impl: Into<_>` found
  --> $DIR/E0283.rs:17:1
   |
LL | impl Into<u32> for Impl {
   | ^^^^^^^^^^^^^^^^^^^^^^^
   = note: and another `impl` found in the `core` crate:
           - impl<T, U> Into<U> for T
             where U: From<T>;
help: try using a fully qualified path to specify the expected types
   |
LL |     let bar = <_ as Into<_>>::into(foo_impl) * 1u32;
   |               +++++++++++++++++++++        ~
help: try using a fully qualified path to specify the expected types
   |
LL |     let bar = <Impl as Into<u32>>::into(foo_impl) * 1u32;
   |               ++++++++++++++++++++++++++        ~

When we encounter a blanket <Ty as Into<Other> impl, look at the From impls so that we can suggest the appropriate Other. We also filter the impl that we'll suggest if the predicate originating this inference chain was a projection for the Output associated type of a math trait:

error[E0284]: type annotations needed
  --> $DIR/issue-70082.rs:7:33
   |
LL |     let y: f64 = 0.01f64 * 1i16.into();
   |                          -      ^^^^
   |                          |
   |                          type must be known at this point
   |
   = note: cannot satisfy `<f64 as Mul<_>>::Output == f64`
help: try using a fully qualified path to specify the expected types
   |
LL |     let y: f64 = 0.01f64 * <i16 as Into<i64>>::into(1i16);
   |                            +++++++++++++++++++++++++    ~

This approach is not generalized for for blanket-impls, so we can end up with suggestions like <_ as Trait<_>>::foo(bar), but at least we don't end up with <_ as Into<_>::into(bar) most of the time. It'd be nice to have a more complete mechanism that does account for all obligations when resolving methods.

[rustbot]

r? @fee1-dead

rustbot has assigned @fee1-dead.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[compiler-errors]

Also, that whole for_suggestion hack is not necessary. You should just rebase these substs onto the trait's associated item (which you can access via assoc_item.trait_item_def_id), and print that, since you're really just printing a method path.

[compiler-errors]

Also, it's probably worthwhile to do this inside of a probe, and instead of doing can_eq just make an ObligationCtxt and use eq + select_where_possible so the infer vars are constrained correctly.

[estebank]

@compiler-errors I'm still to add the probe, but otherwise comments are addressed. I'll do another round of clean up, but I'm intrigued if you think e302e7f is worth it.

[estebank]

@compiler-errors thanks for all the comments! While I have you here, do you think there would be any maintainable way of supporting the general case for "indirect impls that would apply" (like the relationship that Into and From have)? I'm ok with special casing From and TryFrom, but it'd be amazing if we could do it "the right way" instead.

[compiler-errors]

@estebank: No. I thought about it a bit over the last hour, and cannot think of a way of enumerating such "two-step" impls given the way that the trait system works. I'm OK with just special-casing From and TryFrom -- though, please try your best to make it abstract enough to avoid code duplication.

[compiler-errors]

@rustbot author

[estebank]

please try your best to make it abstract enough to avoid code duplication.

Yep, this is effectively a draft, I'll clean it up before it's ready to merge. This was more of a "will this work?" experiment to begin with and published so I could ask you about some of these details in approach.

[compiler-errors]

How does this DefId differ from the one passed as an argument?

[estebank]

This is the DefId of an associated type (like in the tests, Mul::Output, while the other def_id is the one for the method (in the same test, <i16 as Into<_>::into(..)).

[fee1-dead]

r? compiler

[compiler-errors]

Use an ObligationCtxt and a probe

[compiler-errors]

This needs to live in a different method. It's way too deeply nested.

[bors]

☔ The latest upstream changes (presumably #134499) made this pull request unmergeable. Please resolve the merge conflicts.