-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
indicate origin of where type parameter for uninferred types #67277
Labels
A-diagnostics
Area: Messages for errors, warnings, and lints
E-mentor
Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
nikomatsakis
added
A-diagnostics
Area: Messages for errors, warnings, and lints
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
E-mentor
Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion.
labels
Dec 13, 2019
I'm tagging this as E-mentor because it has some rough mentoring instructions. Feel free to reach out to me for help, too. |
@rustbot claim |
Centril
added a commit
to Centril/rust
that referenced
this issue
Dec 15, 2019
…type-parameter, r=estebank Indicate origin of where type parameter for uninferred types Based on rust-lang#65951 (which is not merge yet), fixes rust-lang#67277. This PR improves a little the diagnostic for code like: ``` async fn foo() { bar().await; } async fn bar<T>() -> () {} ``` by showing: ``` error[E0698]: type inside `async fn` body must be known in this context --> unresolved_type_param.rs:9:5 | 9 | bar().await; | ^^^ cannot infer type for type parameter `T` declared on the function `bar` | ... ``` (The ``` declared on the function `bar` ``` part is new) A small side note: `Vec` and `slice` seem to resist this change, because querying `item_name()` panics, and `get_opt_name()` returns `None`. r? @estebank
Centril
added a commit
to Centril/rust
that referenced
this issue
Dec 15, 2019
…type-parameter, r=estebank Indicate origin of where type parameter for uninferred types Based on rust-lang#65951 (which is not merge yet), fixes rust-lang#67277. This PR improves a little the diagnostic for code like: ``` async fn foo() { bar().await; } async fn bar<T>() -> () {} ``` by showing: ``` error[E0698]: type inside `async fn` body must be known in this context --> unresolved_type_param.rs:9:5 | 9 | bar().await; | ^^^ cannot infer type for type parameter `T` declared on the function `bar` | ... ``` (The ``` declared on the function `bar` ``` part is new) A small side note: `Vec` and `slice` seem to resist this change, because querying `item_name()` panics, and `get_opt_name()` returns `None`. r? @estebank
Centril
added a commit
to Centril/rust
that referenced
this issue
Dec 20, 2019
…type-parameter, r=estebank Indicate origin of where type parameter for uninferred types Based on rust-lang#65951 (which is not merge yet), fixes rust-lang#67277. This PR improves a little the diagnostic for code like: ``` async fn foo() { bar().await; } async fn bar<T>() -> () {} ``` by showing: ``` error[E0698]: type inside `async fn` body must be known in this context --> unresolved_type_param.rs:9:5 | 9 | bar().await; | ^^^ cannot infer type for type parameter `T` declared on the function `bar` | ... ``` (The ``` declared on the function `bar` ``` part is new) A small side note: `Vec` and `slice` seem to resist this change, because querying `item_name()` panics, and `get_opt_name()` returns `None`. r? @estebank
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
A-diagnostics
Area: Messages for errors, warnings, and lints
E-mentor
Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Over in #65951, @estebank and I were discussing that we could improve the error message in cases like:
rust/src/test/ui/async-await/unresolved_type_param.rs
Lines 8 to 14 in 3964a55
Presently, we say:
https://github.com/rust-lang/rust/blob/master/src/test/ui/async-await/unresolved_type_param.stderr#L1-L5
but this
T
we reference comes from the definition ofbar
:rust/src/test/ui/async-await/unresolved_type_param.rs
Line 6 in 3964a55
it'd be nice if we said "cannot infer value for type parameter
T
declared on the fnbar
".I believe that name comes from the
TypeParameterDefinition
information that we track as part of a type variable's origin:rust/src/librustc/infer/error_reporting/need_type_info.rs
Lines 159 to 161 in 3964a55
So we could do this by modifying that variant to track the
DefId
of the type parameter and then looking at the parent to derive the context.This issue has been assigned to @ohadravid via this comment.
The text was updated successfully, but these errors were encountered: