When annotations needed, look at impls for more accurate suggestions by estebank · Pull Request #128653 · rust-lang/rust

estebank · 2024-08-04T16:29:16Z

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 Fromimpls 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 · 2024-08-04T16:29:25Z

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 · 2024-08-04T19:25:40Z

+ let mut printer = fmt_printer(self, Namespace::ValueNS);
+ printer.print_def_path(assoc.def_id, identity_method).unwrap();


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.

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.

@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 · 2024-08-04T21:46:27Z

@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 · 2024-08-04T21:49:25Z

@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 · 2024-08-04T21:51:29Z

@rustbot author

estebank · 2024-08-04T22:22:06Z

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 · 2024-08-05T23:01:40Z

+ }
+
+ let filter = if let Some(ty::ProjectionPredicate {
+ projection_term: ty::AliasTerm { def_id, .. },


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

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 · 2024-08-10T16:01:53Z

r? compiler

compiler-errors · 2024-08-19T15:38:49Z

+ let impl_trait_ref =
+ tcx.impl_trait_ref(impl_def_id).unwrap().instantiate(tcx, impl_args);
+ let impl_self_ty = impl_trait_ref.self_ty();
+ if self.infcx.can_eq(param_env, impl_self_ty, self_ty) {


Use an ObligationCtxt and a probe

compiler-errors · 2024-08-19T15:39:31Z

+ if tcx.is_diagnostic_item(sym::blanket_into_impl, impl_def_id)
+ && let Some(did) = tcx.get_diagnostic_item(sym::From)
+ {
+ let mut found = false;
+ tcx.for_each_impl(did, |impl_def_id| {
+ // We had an `<A as Into<B>::into` and we've hit the blanket
+ // impl for `From<A>`. So we try and look for the right `From`
+ // impls that *would* apply. We *could* do this in a generalized
+ // version by evaluating the `where` clauses, but that would be
+ // way too involved to implement. Instead we special case the
+ // arguably most common case of `expr.into()`.
+ let Some(header) = tcx.impl_trait_header(impl_def_id) else {
+ return;
+ };
+ let target = header.trait_ref.skip_binder().args.type_at(0);
+ if filter.is_some() && filter != Some(target) {
+ return;
+ };
+ let target = header.trait_ref.skip_binder().args.type_at(0);
+ let ty = header.trait_ref.skip_binder().args.type_at(1);
+ if ty == self_ty {
+ if target_type {
+ let mut ty_str = format!("{target}");
+ if &ty_str == "_" {
+ ty_str = "/* Type */".to_string();
+ }
+ paths.push(ty_str);
+ } else {
+ paths.push(format!("<{self_ty} as Into<{target}>>::into"));
+ }
+ found = true;
+ }
+ });
+ if found {
+ return;
+ }
+ }


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

bors · 2024-12-19T14:49:14Z

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

compiler-errors · 2025-01-23T18:05:23Z

Don't have the time to get back around to understanding the changes here, sorry! I'm gonna re-roll this so this PR gets more attention.

r? compiler

BoxyUwU · 2025-02-10T20:59:01Z

+ init_expr_hir_id,
+ } => {
+ let mut paths = vec![];
+ if let Some(def_id) = def_id


What is this random def_id what does it mean, please use a different variable name and probably even rename the def_id field on LetBinding. bindings dont have a defid so I don't know what it could even mean to have a defid on InferSourceKind::LetBinding

BoxyUwU · 2025-02-10T21:05:42Z

 let guard: Guard<Arc<usize>> = s.load();
 //~^ ERROR: type annotations needed
 //~| HELP: try using a fully qualified path to specify the expected types
+ // let guard: Guard<Arc<usize>> = <Arc<ArcSwapAny<Arc<usize>>> as Access<Arc<usize>>>::load(&s);


leftover test code?

This was meant to be a marker for myself on what the suggested code should be.

BoxyUwU · 2025-02-10T21:10:59Z

@rustbot author

rustbot · 2026-06-05T19:21:46Z

Some changes occurred in need_type_info.rs

cc @lcnr

Some changes occurred in compiler/rustc_attr_parsing

cc @jdonszelmann, @JonathanBrouwer

rustbot · 2026-06-05T19:21:48Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

When encountering an expression that needs type annotations, if we have the trait `DefId` we look for all the `impl`s 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; | ++++++++++++++++++++++++++ ~ ``` This approach does not account for blanket-impls, so we can end up with suggestions like `<_ as Into<_>>::into(foo)`. It'd be nice to have a more complete mechanism that does account for all obligations when resolving methods. Do not suggest `path::to<impl Trait for Type>::method` In the pretty-printer, we have a weird way to display fully-qualified for non-local impls, where we show a regular path, but the section corresponding to the `<Type as Trait>` we use non-syntax for it like `path::to<impl Trait for Type>`. It should be `<Type for path::to::Trait>`, but this is only better when we are printing code to be suggested, not to find where the `impl` actually is, so we add a new flag to the printer for this. Special case `Into` suggestion to look for `From` `impl`s When we encounter a blanket `<Ty as Into<Other>` `impl`, look at the `From` `impl`s so that we can suggest the appropriate `Other`: ``` 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<i32>>::into(1i16); | +++++++++++++++++++++++++ ~ help: try using a fully qualified path to specify the expected types | LL | let y: f64 = 0.01f64 * <i16 as Into<i64>>::into(1i16); | +++++++++++++++++++++++++ ~ help: try using a fully qualified path to specify the expected types | LL | let y: f64 = 0.01f64 * <i16 as Into<i128>>::into(1i16); | ++++++++++++++++++++++++++ ~ help: try using a fully qualified path to specify the expected types | LL | let y: f64 = 0.01f64 * <i16 as Into<isize>>::into(1i16); | +++++++++++++++++++++++++++ ~ help: try using a fully qualified path to specify the expected types | LL | let y: f64 = 0.01f64 * <i16 as Into<f32>>::into(1i16); | +++++++++++++++++++++++++ ~ help: try using a fully qualified path to specify the expected types | LL | let y: f64 = 0.01f64 * <i16 as Into<f64>>::into(1i16); | +++++++++++++++++++++++++ ~ help: try using a fully qualified path to specify the expected types | LL | let y: f64 = 0.01f64 * <i16 as Into<AtomicI16>>::into(1i16); | +++++++++++++++++++++++++++++++ ~ ``` Suggest an appropriate type for a binding of method chain Do the same we do with fully-qualified type suggestions to the suggestion to specify a binding type: ``` error[E0282]: type annotations needed --> $DIR/slice-pattern-refutable.rs:14:9 | LL | let [a, b, c] = Zeroes.into() else { | ^^^^^^^^^ | help: consider giving this pattern a type | LL | let [a, b, c]: _ = Zeroes.into() else { | +++ help: consider giving this pattern a type | LL | let [a, b, c]: [usize; 3] = Zeroes.into() else { | ++++++++++++ ``` review comments - Pass `ParamEnv` through - Remove now-unnecessary `Formatter` mode - Rework the way we pick up the bounds Add naïve mechanism to filter `Into` suggestions involving math ops ``` 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<f64>>::into(1i16); | +++++++++++++++++++++++++ ~ ``` Note that we only suggest `Into<f64>`, and not `Into<i32>`, `Into<i64>`, `Into<i128>`, `Into<isize>`, `Into<f32>` or `Into<AtomicI16>`. Replace `_` with `/* Type */` in let binding type suggestion Rework the `predicate` "trafficking" to be more targetted Rename `predicate` to `originating_projection`. Pass in only the `ProjectionPredicate` instead of the `Predicate` to avoid needing to destructure as much. Use `prove`/`ObligationCtxt` instead of `can_eq` Account for impl/trait difference Do not suggest `<_ as Into<_>>` blanket impl We will usually have a better, more specific, alternative suggestion.

rust-log-analyzer · 2026-06-05T19:45:53Z

The job pr-check-2 failed! Check out the build log: (web)(plain enhanced)(plain)

Click to see the possible cause of the failure (guessed by this bot)

rust-bors · 2026-07-13T23:28:41Z

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

rustbot assigned fee1-dead Aug 4, 2024

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Aug 4, 2024

compiler-errors reviewed Aug 4, 2024
View reviewed changes

Comment threadcompiler/rustc_middle/src/ty/print/pretty.rs Outdated

compiler-errors suggested changes Aug 4, 2024
View reviewed changes

compiler-errors reviewed Aug 4, 2024
View reviewed changes

Comment threadcompiler/rustc_trait_selection/src/error_reporting/infer/need_type_info.rs Outdated

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 4, 2024

estebank force-pushed the ambiguity-suggestion-2 branch from 8020c4c to eeeae60Compare August 5, 2024 21:48

compiler-errors suggested changes Aug 5, 2024
View reviewed changes

estebank force-pushed the ambiguity-suggestion-2 branch 2 times, most recently from a158bbc to ac19deeCompare August 8, 2024 17:48

estebank added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Aug 8, 2024

rustbot assigned TaKO8Ki and unassigned fee1-dead Aug 10, 2024

compiler-errors assigned compiler-errors and unassigned TaKO8Ki Aug 10, 2024

compiler-errors reviewed Aug 19, 2024
View reviewed changes

Comment threadcompiler/rustc_trait_selection/src/error_reporting/infer/need_type_info.rs Outdated

compiler-errors reviewed Aug 19, 2024
View reviewed changes

Comment threadcompiler/rustc_trait_selection/src/error_reporting/infer/need_type_info.rs Outdated

compiler-errors reviewed Aug 19, 2024
View reviewed changes

Comment threadcompiler/rustc_trait_selection/src/error_reporting/infer/need_type_info.rs Outdated

compiler-errors suggested changes Aug 19, 2024
View reviewed changes

rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Aug 19, 2024

rustbot added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Aug 19, 2024

This comment was marked as resolved.
Sign in to view

estebank force-pushed the ambiguity-suggestion-2 branch from ac19dee to adc3ea6Compare August 20, 2024 23:01

This comment was marked as outdated.
Sign in to view

estebank force-pushed the ambiguity-suggestion-2 branch from adc3ea6 to 50f81d2Compare August 30, 2024 01:04

traviscross added the A-diagnostics Area: Messages for errors, warnings, and lints label Sep 29, 2024

estebank force-pushed the ambiguity-suggestion-2 branch from 50f81d2 to 78f1303Compare November 6, 2024 00:51

estebank added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Nov 6, 2024

rustbot assigned BoxyUwU and unassigned compiler-errors Jan 23, 2025

BoxyUwU reviewed Feb 10, 2025
View reviewed changes

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 10, 2025

estebank force-pushed the ambiguity-suggestion-2 branch from 78f1303 to 8417e1aCompare June 5, 2026 19:21

rustbot added the A-attributes Area: Attributes (`#[…]`, `#![…]`) label Jun 5, 2026

estebank force-pushed the ambiguity-suggestion-2 branch from 8417e1a to dec73f9Compare June 5, 2026 19:25

		let mut printer = fmt_printer(self, Namespace::ValueNS);
		printer.print_def_path(assoc.def_id, identity_method).unwrap();

Uh oh!

Uh oh!

Conversation

estebank commented Aug 4, 2024• edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Aug 4, 2024

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

compiler-errorsAug 4, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

estebank commented Aug 4, 2024

Uh oh!

compiler-errors commented Aug 4, 2024

Uh oh!

Uh oh!

compiler-errors commented Aug 4, 2024

Uh oh!

estebank commented Aug 4, 2024

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

fee1-dead commented Aug 10, 2024

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

This comment was marked as resolved.

This comment was marked as outdated.

bors commented Dec 19, 2024

Uh oh!

compiler-errors commented Jan 23, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

BoxyUwU commented Feb 10, 2025

Uh oh!

rustbot commented Jun 5, 2026

Uh oh!

rustbot commented Jun 5, 2026

Uh oh!

rust-log-analyzer commented Jun 5, 2026

Uh oh!

rust-borsBot commented Jul 13, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

estebank commented Aug 4, 2024•
edited by rustbot
Loading

compiler-errorsAug 4, 2024•
edited
Loading