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

detect when unconstrained type parameters could be resolved by a closure return type #40014

Closed
nikomatsakis opened this issue Feb 21, 2017 · 12 comments · Fixed by #63507
Closed
Labels
A-diagnostics Area: Messages for errors, warnings, and lints C-enhancement Category: An issue proposing an enhancement or a PR with one.

Comments

@nikomatsakis
Copy link
Contributor

nikomatsakis commented Feb 21, 2017

Building on the changes in #39361, it'd be nice to suggest when the user ought to annotate a closure return type, as I think many users are not even aware this is possible. Example:

fn main() {
    let _v = || [];
}

I'd like to suggest something like :

error[E0101]: cannot determine a type for this expression: unconstrained type
 --> <anon>:2:17
  |
2 |     let _v = || [];
  |              -- ^^ cannot resolve type of expression
                 |
                 consider annotating the return type of this closure like so `|| -> TYPE { [] }`

Not sure the best way to phrase that yet. =)

cc @cengizio -- interested in following up on this? I can help mentor it.

cc @estebank @jonathandturner -- any thoughts on how to phrase the suggestion?

@sophiajt
Copy link
Contributor

sophiajt commented Feb 21, 2017

I'd probably use a suggestion with a span, rather than trying to fit it. Or... maybe something like:

error[E0101]: cannot determine a type for this expression: unconstrained type
 --> <anon>:2:17
  |
2 |     let _v = || [];
  |              -- ^^ cannot resolve type of expression
                 |
                 needs return type, for example: `|| -> TYPE { [] }`

@cengiz-io
Copy link
Contributor

Hello @nikomatsakis

I'll be working on this.

Thanks for reporting and mentoring!

@nikomatsakis
Copy link
Contributor Author

@jonathandturner so actually I'm not sure that the main ^^ adds any value here. Maybe something like "cannot infer the return type for this closure" as the "main" error, combined with a "suggestion" for how to annotate:

error[E0101]: cannot infer the return type of this closure
 --> <anon>:2:17
  |
2 |     let _v = || [];
  |                 ^^ cannot infer the return type of this closure
  suggestion: add an explicit annotation like `|| -> [XXX; 0] { [] }`

@sophiajt
Copy link
Contributor

Interesting, how about if the ^^ was the suggestion?

error[E0101]: cannot infer the return type of this closure
 --> <anon>:2:17
  |
2 |     let _v = || [];
  |              ^^ needs return type, for example: `|| -> TYPE { [] }`

@sophiajt
Copy link
Contributor

I take it back, I think yours is better since the error should be about inference.

@nikomatsakis
Copy link
Contributor Author

@jonathandturner it does feel like saying the exact same thing (as i wrote it) is suboptimal...

@sophiajt
Copy link
Contributor

How about?

error[E0101]: cannot infer the return type of this closure
 --> <anon>:2:17
  |
2 |     let _v = || [];
  |              ^^ can't infer return type, use: `|| -> TYPE { [] }`

@nikomatsakis
Copy link
Contributor Author

Maybe this? Or do we try to avoid "labels" that assume you have read the "main" message?

error[E0101]: cannot infer the return type of this closure
 --> <anon>:2:17
  |
2 |     let _v = || [];
  |              ^^ to specify return type, use: `|| -> TYPE { [] }`

@sophiajt
Copy link
Contributor

do we try to avoid "labels" that assume you have read the "main" message?

Generally, yeah. I did a quick survey when we were doing the error message redesign, and most people saw the label first. So I just assume people don't see the main message now, to be on the safe side.

@nikomatsakis
Copy link
Contributor Author

I am mildly worried that putting the tip 'in line' will also run into trouble because it will tend to wrap.

@sophiajt
Copy link
Contributor

It could go in attached note...

@Mark-Simulacrum Mark-Simulacrum added the A-diagnostics Area: Messages for errors, warnings, and lints label May 24, 2017
@Mark-Simulacrum Mark-Simulacrum added the C-enhancement Category: An issue proposing an enhancement or a PR with one. label Jul 26, 2017
@estebank
Copy link
Contributor

estebank commented Aug 13, 2019

#63507 (addressing #63506) will cause this case to suggest turning it into a boxed fn trait:

error[E0282]: type annotations needed for the closure
 --> file7.rs:2:17
  |
2 |     let _v = || [];
  |         --      ^^ cannot infer type
  |         |
  |         consider giving `_v` a boxed closure type like `Box<dyn Fn() -> [_; 0]>`

Suggesting annotating the closure itself would probably be better.


Edit: changed to be

error[E0282]: type annotations needed for the closure `fn() -> [_; 0]`
  --> $DIR/suggest-closure-return-type-3.rs:2:17
   |
LL |     let _v = || [];
   |                 ^^ cannot infer type
help: give this closure an explicit return type without `_` placeholders
   |
LL |     let _v = || -> [_; 0] { [] };
   |                 ^^^^^^^^^^^    ^

Centril added a commit to Centril/rust that referenced this issue Aug 14, 2019
…ntril

When needing type annotations in local bindings, account for impl Trait and closures

Fix rust-lang#46680, fix rust-lang#63504, fix rust-lang#63506, fix rust-lang#40014, cc rust-lang#63502.
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 C-enhancement Category: An issue proposing an enhancement or a PR with one.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants