Calling .into() on argument that expects Into<Type> gives confusing error

When calling (x: Type)::into() in a fn that expects Into<Type> we currently emit:

error[E0283]: type annotations needed
    --> src/librustc_resolve/late/diagnostics.rs:1143:21
     |
1143 |                 err.span_note(spans.into(), "these named lifetimes are available to use");
     |                     ^^^^^^^^^ ------------ this method call resolves to `T`
     |                     |
     |                     cannot infer type for type parameter `S` declared on the method `span_note`
     |
     = note: cannot resolve `_: std::convert::Into<rustc_span::MultiSpan>`

We should check whether T == MultiSpan and suggest the removal of the into() call.

@rustbot

@rustbot claim

@Duddino

@Duddino feel free to reach out either on this ticket or on a PR, but be warned that this has the potential to be quite involved. It is a great introduction to how some parts of rustc fit together though.

I've been looking into this for a while now, and my idea was to: Check if there a .into() call, check if the type of self was T and finally check if the argument of the function was Into. However I cannot figure how to get the type of Self. As far as my understanding goes, rustc hasn't yet inferred the type.

You can query the in-progress type table with the HirId for the expression. You're gonna have an Expr with a kind: ExprKind::MethodCall(method_name, [args including self]). From the first argument in that variant you can take the first element and get the expression for foo in foo.into(). Then you can use the HirId for that expression to do

let tables = tcx.typeck_tables_of(tcx.hir().local_def_id(hir_id));
let opt_ty = tables.node_type_opt(expr.hir_id));

I do not know if we will have populated expr's type by then, but if we have, then that will give you the type of Self. Then, if you're in an FnCtxt you can use can_coerce to see if the inferred type for expr can be coerced to MultiSpan in the original example. I know this is a bit vague, but for this is inherently exploratory work :)

@Duddino

Hi, are you still working on this issue @Duddino?

No, feel free to claim it if you want

…

On Wed, 5 Aug 2020, 19:28 Alex Macleod, ***@***.***> wrote: Hi, are you still working on this issue @Duddino <https://github.com/Duddino>? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#71252 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALI7FQGHTBGGBLMHLL2XR3LR7GJCJANCNFSM4MK45OEQ> .

@rustbot

@rustbot release-assignment

Detect when method call on argument could be removed to fulfill faile…

Rollup merge of rust-lang#121100 - estebank:issue-71252, r=compiler-e…

Unrolled build for rust-lang#121100

Navigation Menu

Repository navigation

Calling `.into()` on argument that expects `Into<Type>` gives confusing error #71252

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Calling .into() on argument that expects Into<Type> gives confusing error #71252

Description

Activity

Duddino commented on Apr 18, 2020

estebank commented on Apr 18, 2020

Duddino commented on Apr 21, 2020

estebank commented on Apr 21, 2020

Alexendoo commented on Aug 5, 2020

Duddino commented on Aug 5, 2020

Alexendoo commented on Aug 5, 2020

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Calling `.into()` on argument that expects `Into<Type>` gives confusing error #71252