Skip to content
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

Closed
nikomatsakis opened this issue Dec 13, 2019 · 2 comments · Fixed by #67285
Closed

indicate origin of where type parameter for uninferred types #67277

nikomatsakis opened this issue Dec 13, 2019 · 2 comments · Fixed by #67285
Assignees
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
Copy link
Contributor

nikomatsakis commented Dec 13, 2019

Over in #65951, @estebank and I were discussing that we could improve the error message in cases like:

async fn foo() {
bar().await;
//~^ ERROR type inside `async fn` body must be known in this context
//~| NOTE cannot infer type for `T`
//~| NOTE the type is part of the `async fn` body because of this `await`
//~| NOTE in this expansion of desugaring of `await`
}

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 of bar:

async fn bar<T>() -> () {}

it'd be nice if we said "cannot infer value for type parameter T declared on the fn bar".

I believe that name comes from the TypeParameterDefinition information that we track as part of a type variable's origin:

if let TypeVariableOriginKind::TypeParameterDefinition(name) = var_origin.kind {
return (name.to_string(), Some(var_origin.span));
}

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.

@nikomatsakis 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
@nikomatsakis
Copy link
Contributor Author

I'm tagging this as E-mentor because it has some rough mentoring instructions. Feel free to reach out to me for help, too.

@ohadravid
Copy link
Contributor

@rustbot claim

@rustbot rustbot self-assigned this Dec 13, 2019
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
@bors bors closed this as completed in 403bb09 Dec 20, 2019
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.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants