Point at definition of item with type parameters that couldn't be inferred by estebank · Pull Request #153890 · rust-lang/rust

estebank · 2026-03-14T23:21:45Z

When calling a function with type parameters that are unconstrained by the call expression, we mention the type parameter that couldn't be inferred, but the user previously didn't see where the name was coming from. By pointing at the function itself, including the type parameter, we give better context on what they should have done, specially when the inference machinery fails to provide any other context.

error[E0282]: type annotations needed
  --> $DIR/unresolved_type_param.rs:9:5
   |
LL |     bar().await;
   |     ^^^ cannot infer type of the type parameter `T` declared on the function `bar`
   |
note: type must be known for this
  --> $DIR/unresolved_type_param.rs:6:1
   |
LL | async fn bar<T>() -> () {}
   | ^^^^^^^^^^^^^^^^^^^^^^^
help: consider specifying the generic argument
   |
LL |     bar::<T>().await;
   |        +++++

We should further refine when we present this info to make sure we don't provide redundant notes in some cases. Also, there are cases (like those in issue 94969) that don't provide any new information with this change.

rustbot · 2026-03-14T23:21:49Z

Some changes occurred in need_type_info.rs

cc @lcnr

rustbot · 2026-03-14T23:21:51Z

r? @jieyouxu

rustbot has assigned @jieyouxu.
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

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: compiler
compiler expanded to 69 candidates
Random selection from 15 candidates

jieyouxu

Initial review pass

View changes since this review

tests/ui/array-slice-vec/vector-no-ann.stderr

jieyouxu · 2026-03-15T08:04:43Z

tests/ui/associated-type-bounds/dedup-normalized-2-higher-ranked.current.stderr

+note: type must be known for type parameter in this
+  --> $DIR/dedup-normalized-2-higher-ranked.rs:25:1
+   |
+LL | fn impls<T: for<'b> Bound<'b, U>, U>(_: T) {}
+   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


Discussion (non-blocking): hm, the phrasing on this stderr looks a little bit strange:

The current wording doesn't say the concrete types of which type parameter we don't know about

Saying "this" I suppose works, it just reads somewhat strange

I wonder if it's worth the trouble to say something more like

the concrete type of type parameter T must be known in impls

... or

the concrete type of type parameter T must be known in this function

s/function/$item_kind/

That being said, I don't think this PR needs to block on that.

I agree that the output is not ideal. I'd tried an initial attempt at getting the same information from the existing label in the message, but I think I might have to do some mild refactoring to accomplish that. I agree that the wording should be closer to what you propose.

tests/ui/associated-type-bounds/duplicate-bound-err.stderr

jieyouxu · 2026-03-15T08:07:50Z

tests/ui/closures/issue-99565.stderr

+note: type must be known for type parameter in this
+  --> $DIR/issue-99565.rs:3:1
+   |
+LL | fn foo<T, U>(_: U) {}
+   | ^^^^^^^^^^^^^^^^^^


Remark: hm, my first reaction when reading this diff is that maybe this is slightly redundant?

The inline note above says

cannot infer type of the type parameter T declared on the function foo

which feels a bit redundant with the new outline note

note: type must be known for type parameter in this

I guess I could see the explicit reference being useful since otherwise the original inline note does not actually point at the definition of foo

EDIT: now I recall you mentioned this specifically in the description lol

We should further refine when we present this info to make sure we don't provide redundant notes in some cases. Also, there are cases (like those in issue 94969) that don't provide any new information with this change.

jieyouxu · 2026-03-15T08:08:55Z

tests/ui/const-generics/defaults/rp_impl_trait_fail.stderr

+note: type must be known for type parameter in this
+  --> $DIR/rp_impl_trait_fail.rs:16:1
+   |
+LL | fn uwu<const N: u8>() -> impl Traitor<N> {
+   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


Question: wait hold on, we call N here a const (generic) parameter, not a type parameter usually right?

yes, this is indeed incorrect

jieyouxu · 2026-03-15T08:11:11Z

tests/ui/const-generics/infer/issue-77092.stderr

+note: type must be known for type parameter in this
+  --> $DIR/issue-77092.rs:3:1
+   |
+LL | fn take_array_from_mut<T, const N: usize>(data: &mut [T], start: usize) -> &mut [T; N] {
+   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


Question: this is the reason I suggested a wording nit previously, while technically we can say there's 1 type parameter T and one const generic parameter N on this item so it isn't ambiguous, it's not immediately straightforward that we mean N and not T here.

Wait, actually, this note would be slightly misleading then, the one we can't infer is actually the const generic parameter N not the type parameter T looking at the inline note above, right?

jieyouxu · 2026-03-15T08:12:27Z

tests/ui/const-generics/infer/one-param-uninferred.stderr

+note: type must be known for type parameter in this
+  --> $DIR/one-param-uninferred.rs:2:1
+   |
+LL | fn foo<const N: usize, const M: usize>() -> [u8; N] {
+   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


Remark: likewise, there are actually two const generic parameters on foo and the one we cannot infer is M, so the note as-is doesn't really tell that nuance.

jieyouxu · 2026-03-15T08:15:04Z

tests/ui/delegation/generics/trait-impl-wrong-args-count.stderr

+note: type must be known for type parameter in this
+  --> $DIR/trait-impl-wrong-args-count.rs:9:9
+   |
+LL |         pub fn bar2<A, B, C, D, E, F, const X: usize, const Y: bool>(x: &super::XX) {}


Remark: likewise, hard to tell when there's not just only 1 type/const generic parameters.

jieyouxu · 2026-03-15T08:21:55Z

tests/ui/inference/need_type_info/issue-113264-incorrect-impl-trait-in-path-suggestion.stderr

+note: type must be known for type parameter in this
+  --> $DIR/issue-113264-incorrect-impl-trait-in-path-suggestion.rs:6:5
+   |
+LL |     fn owo(&self, _: Option<&impl T>) {}


Discussion: hm, this is slightly more interesting, this is an APIT which we do not explicitly name a type parameter right? I wonder if in such cases we need to subspan highlight the impl T itself since you can have multiple impl Ts that users can only tell apart based on their source positions

fn foo(x: impl T, y: impl T) {}

The note should point at the bound itself, as well as the item name (that will require some changes to make that additional work with structured diagnostics).

jieyouxu · 2026-03-15T08:23:20Z

tests/ui/inference/issue-83606.stderr

+note: type must be known for type parameter in this
+  --> $DIR/issue-83606.rs:3:1
+   |
+LL | fn foo<const N: usize>(_: impl std::fmt::Display) -> [usize; N] {
+   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


Remark: hm, and there can be a case where a user mixes explicit type params / const generic params and APITs

jieyouxu · 2026-03-15T08:27:24Z

@rustbot author

rustbot · 2026-03-15T08:27:29Z

Reminder, once the PR becomes ready for a review, use @rustbot ready.

…erred When calling a function with type parameters that are unconstrained by the call expression, we mention the type parameter that couldn't be inferred, but the user previously didn't see where the name was coming from. By pointing at the function itself, including the type parameter, we give better context on what they should have done, specially when the inference machinery fails to provide any other context. ``` error[E0282]: type annotations needed --> $DIR/unresolved_type_param.rs:9:5 | LL | bar().await; | ^^^ cannot infer type of the type parameter `T` declared on the function `bar` | note: type must be known for this --> $DIR/unresolved_type_param.rs:6:1 | LL | async fn bar<T>() -> () {} | ^^^^^^^^^^^^^^^^^^^^^^^ help: consider specifying the generic argument | LL | bar::<T>().await; | +++++ ``` We should further refine when we present this info to make sure we don't provide redundant notes in some cases. Also, there are cases (like those in issue 94969) that don't provide any new information with this change.

rustbot · 2026-03-17T21:25:38Z

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.

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. WG-trait-system-refactor The Rustc Trait System Refactor Initiative (-Znext-solver) labels Mar 14, 2026

rustbot assigned jieyouxu Mar 14, 2026

jieyouxu reviewed Mar 15, 2026

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 Mar 15, 2026

This comment has been minimized.

Sign in to view

estebank force-pushed the issue-94969 branch from 283bf92 to 35308c1 Compare March 17, 2026 21:25

estebank marked this pull request as draft March 18, 2026 01:59

Uh oh!

Conversation

estebank commented Mar 14, 2026

Uh oh!

rustbot commented Mar 14, 2026

Uh oh!

rustbot commented Mar 14, 2026

Uh oh!

jieyouxu left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

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!

Uh oh!

jieyouxu Mar 15, 2026 • 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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jieyouxu commented Mar 15, 2026

Uh oh!

rustbot commented Mar 15, 2026

Uh oh!

This comment has been minimized.

rustbot commented Mar 17, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

jieyouxu left a comment •

edited by rustbot

Loading

jieyouxu Mar 15, 2026 •

edited

Loading