Tracking Issue for post #89862 cleanup

[lcnr]

#89862 rewrote the inference error reporting, but slightly worsened some causes or requires some additional improvements.

• readd a special diagnostic for for loops
• maybe readd handling for try expressions ?
• add InferSource for x.into() to <Type as Into<_>>::into(x)
• add ty_msg back if no infer source is found
• in the suggested type, try to only print _ for things while are fully inferred and use some different stuff for unresolved inference vars, e.g "specify the generic param T for Foo<i32, T, _>"
  • remember the used parameters in ty_to_string for this
• remember the inferred type for InferSource::GenericArg and use them to compute the cost and for the error msg, generally improve cost computation, e.g. channel()
  • change source_cost to improve the diagnostics when using channel().
• impl_candidates in emit_inference_failure_err IMPORTANT
• figure out how to not mention macro internals in error messages.
• fix the explicit FIXME(#89862) in some tests
• inference var origins: https://github.com/rust-lang/rust/pull/89862/files#r870179263
• figure out how to best deal with rewrite error handling for unresolved inference vars #89862 (comment)
• autoborrow method call
• ui/impl-trait/diagnostics/fully-qualified-path-impl-trait.rs fixme
• help: type parameter declared here readd maybe

[estebank]

https://github.com/rust-lang/rust/pull/89862/files#diff-61d51b814405f1781530e7e1aa7ec33300b9a60d2338870adcae2404abea109e This test has a small regression. In method chains with inference errors, we should specify the full type of the generic that wasn't detected.

[aliemjay]

another regression I stumbled on: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=56db000bf6de1f611185c769fe098d5e

fn main() {
    |var: _| { // `_` placeholder is necessary.
    //^ Past : consider giving this closure parameter a type
        var.abc()
        //^ Present : cannot infer type
    };
}

[lcnr]

closing this.

most of these points have been implemented while the remaining ones are either difficult to implement, underspecified or not worth the complexity. Any future improvements are worth it regardless of whether they are mentioned in this issue