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

impl trait error message around 'static is probably confusing #48467

Closed
nikomatsakis opened this issue Feb 23, 2018 · 7 comments
Closed

impl trait error message around 'static is probably confusing #48467

nikomatsakis opened this issue Feb 23, 2018 · 7 comments

Comments

@nikomatsakis
Copy link
Contributor

@nikomatsakis nikomatsakis commented Feb 23, 2018

The error message for this example seems potentially confusing:

#![feature(dyn_trait)]
#![feature(conservative_impl_trait)]
#![feature(underscore_lifetimes)]

fn a<T>(items: &[T]) -> Box<impl Iterator> {
    Box::new(items.iter()) //~ ERROR cannot infer an appropriate lifetime
}

fn main() { }

I get:

error[E0621]: explicit lifetime required in the type of `items`
 --> src/main.rs:5:29
  |
5 | fn a<T>(items: &[T]) -> Box<impl Iterator> {
  |         -----               ^^^^^^^^^^^^^ lifetime `'static` required
  |         |
  |         consider changing the type of `items` to `&'static [T]`

What's going wrong here is that impl Iterator can only capture lifetimes that it names, and this one doesn't name any lifetimes. It can be fixed by changing to impl Iterator + '_ -- this is probably what we want to suggest? I'm not sure how best to phrase this, suggestions welcome.

cc @cramertj @estebank

@estebank
Copy link
Contributor

@estebank estebank commented Feb 23, 2018

I've seen other cases of this too, it'd be great to improve it.

error[E0XXX]: ambiguous lifetime for `impl Iterator`
 --> src/main.rs:5:29
  |
5 | fn a<T>(items: &[T]) -> Box<impl Iterator> {
  |                             ^^^^^^^^^^^^^ this trait bound implies lifetime `'static`
help: add a lifetime binding to remove the `'static` requirement
  |
5 | fn a<T>(items: &[T]) -> Box<impl Iterator + '_> {
  |                             ^^^^^^^^^^^^^^^^^^
help: otherwise, change the type of `items` to `&'static [T]` to satisfy the `'static` requirement
  |
5 | fn a<T>(items: &'static [T]) -> Box<impl Iterator> {
  |                ^^^^^^^^^^^^

@nikomatsakis
Copy link
Contributor Author

@nikomatsakis nikomatsakis commented Feb 23, 2018

@estebank

Suggesting both might be good. However, this label is inaccurate:

this trait bound implies lifetime 'static

That trait bound forbids us from capturing the anonymous lifetime, because it is not mentioned anywhere, but it does not imply 'static. For example, we could capture values of type T, which is not known to be static. Obviously we won't be able to express all that subtlety, but maybe we can say something like "impl Trait types can only capture lifetimes that they reference"?

@estebank
Copy link
Contributor

@estebank estebank commented Feb 23, 2018

Your suggested text seems great to me for the label, while this is one of the error messages that would benefit greatly from --teach.

@kornelski
Copy link
Contributor

@kornelski kornelski commented Jan 5, 2019

This comes up in Futures-heavy code a lot. In such cases the real solution is to use Arc, but users are sent chasing impossible lifetime annotations.

My suggestion is: No matter what, don't say 'static.

Users don't write Box< + 'static> explicitly by themselves. They see it only in the context of &'static str or static FOO: &'static.

When Rust points to a &-argument, and says it has to be 'static, users understand it literally that arg: &'static Foo is the only allowed solution, which leads to despair.

"Temporary references are not allowed here" may be guiding them towards better solutions.

@kornelski
Copy link
Contributor

@kornelski kornelski commented Jan 5, 2019

Another case from user forum:

type EvalFn = Fn() -> (u8);                            
fn take_callback(f: &EvalFn) -> u8 {
    1
} 

fn test(arg: Option<&u8>) -> (u8) {
    let closure = || arg.cloned().unwrap();
    take_callback(&closure)
}  

The error points that the argument should be 'static rather than the real (quite unobvious) solution of type EvalFn<'a> = Fn() -> (u8) + 'a.

@nox
Copy link
Contributor

@nox nox commented Mar 4, 2019

I hit this when implementing inert_derive.

https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=dcbcd6a9d8e7b989ac3f574044557c64

In my case I can't seem to find a way to tell rustc that my impl ToTokens value is 'static.

@estebank
Copy link
Contributor

@estebank estebank commented Mar 4, 2019

A separate situation that would need to be handled is the following:

#![feature(dyn_trait)]
#![feature(conservative_impl_trait)]
#![feature(underscore_lifetimes)]

fn a<'a, T>(items: &'a [T]) -> Box<impl Iterator> {
    Box::new(items.iter())
}

fn main() { }

where the suggestion would need to be to add + 'a constraint, but currently outputs the general lifetime error:

error[E0495]: cannot infer an appropriate lifetime for autoref due to conflicting requirements
 --> file.rs:6:20
  |
6 |     Box::new(items.iter())
  |                    ^^^^
  |
note: first, the lifetime cannot outlive the lifetime 'a as defined on the function body at 5:6...
 --> file.rs:5:6
  |
5 | fn a<'a, T>(items: &'a [T]) -> Box<impl Iterator> {
  |      ^^
note: ...so that reference does not outlive borrowed content
 --> file.rs:6:14
  |
6 |     Box::new(items.iter())
  |              ^^^^^
  = note: but, the lifetime must be valid for the static lifetime...
note: ...so that return value is valid for the call
 --> file.rs:5:36
  |
5 | fn a<'a, T>(items: &'a [T]) -> Box<impl Iterator> {
  |                                    ^^^^^^^^^^^^^
Centril added a commit to Centril/rust that referenced this issue Apr 1, 2019
…, r=pnkfelix

Suggest using anonymous lifetime in `impl Trait` return

Fix rust-lang#48467.

r? @nikomatsakis
Centril added a commit to Centril/rust that referenced this issue Apr 1, 2019
…, r=pnkfelix

Suggest using anonymous lifetime in `impl Trait` return

Fix rust-lang#48467.

r? @nikomatsakis
@bors bors closed this in #58919 Apr 1, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants