Skip to content

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

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

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.
# for free to join this conversation on GitHub. Already have an account? # 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