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

"use of undeclared lifetime name 'static" is misleading #40661

Closed
solson opened this issue Mar 20, 2017 · 8 comments
Closed

"use of undeclared lifetime name 'static" is misleading #40661

solson opened this issue Mar 20, 2017 · 8 comments
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-resolve Area: Name resolution E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion.

Comments

@solson
Copy link
Member

solson commented Mar 20, 2017

Code: https://is.gd/6L8tEl

fn foo<'a: 'static>() {}

Output:

rustc 1.17.0-nightly (b1e31766d 2017-03-03)
error[E0261]: use of undeclared lifetime name `'static`
 --> <anon>:1:12
  |
1 | fn foo<'a: 'static>() {}
  |            ^^^^^^^ undeclared lifetime

Expectation:

<'a: 'static> is unnecessary (you can just use 'static in place of 'a), but maybe we should accept it? At any rate, the error message is misleading - 'static is the one globally declared lifetime. If we want to reject this code, the error message should not imply 'static is undefined, but rather that you just don't need the 'a lifetime.

@jseyfried jseyfried added A-diagnostics Area: Messages for errors, warnings, and lints A-resolve Area: Name resolution E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. labels Mar 20, 2017
@jseyfried
Copy link
Contributor

I believe we'll want to check for 'static here.

@eugene-bulkin
Copy link

The right move here would be to reject 'static here because 'a is superfluous in that scenario, right? I'm not entirely sure what the performance implications would be of just accepting it since it's the same as doing foo<'static>.

Since it would be unnecessary, would be more appropriate to reject the code telling the user to just use 'static instead?

@adamransom
Copy link
Contributor

I'd like to work on this, if it is still open (and/or available for mentoring)!

@jseyfried
Copy link
Contributor

@adamransom
Yeah, go ahead! Feel free to ask questions here or ping me on IRC (jseyfried in #rustc or #rust-internals).

@jseyfried
Copy link
Contributor

@eugene-bulkin

it's the same as doing foo<'static>

fn foo<'static>() {} isn't allowed.

would [it] be more appropriate to reject the code telling the user to just use 'static instead?

I think it would appropriate to reject the code and tell the user not to use a lifetime parameter at all -- there's never a need for a parameter that must always be 'static.

That being said, we also might want to allow it for consistency, perhaps with a warning (lint).
cc @rust-lang/lang @petrochenkov

@eugene-bulkin
Copy link

fn foo<'static>() {} isn't allowed.

Oh, well in that case it makes even more sense to just warn the user that the parameter is unnecessary; an error might be overkill, but a warning would seem reasonable.

@adamransom
Copy link
Contributor

@jseyfried Great, I'll work on adding a warning as we discussed in IRC.

@petrochenkov
Copy link
Contributor

I think it would appropriate to reject the code and tell the user not to use a lifetime parameter at all -- there's never a need for a parameter that must always be 'static.
That being said, we also might want to allow it for consistency, perhaps with a warning (lint).

Both seems reasonable.
Maybe this warning can be shoehorned into some existing lint? Creating a new one just for this seems wasteful. (Maybe this should be an error just to avoid adding a new lint.)

frewsxcv added a commit to frewsxcv/rust that referenced this issue Mar 25, 2017
Add warning for use of lifetime parameter with 'static bound

Previously a `'static` lifetime bound would result in an `undeclared lifetime` error when compiling, even though it could be considered valid.

However, it is unnecessary to use it as a lifetime bound so we present the user with a warning instead and suggest using the `'static` lifetime directly, in place of the lifetime parameter. We can change this to an error (or warning with lint) if that's decided to be more appropriate.

Example output:
```
warning: unnecessary lifetime parameter `'a`
 --> ../static-lifetime-bound.rs:3:10
  |
3 | fn f<'a: 'static>(val: &'a i32) {
  |      ^^^^^^^^^^^
  |
  = help: you can use the `'static` lifetime directly, in place `'a`
```

Fixes rust-lang#40661

r? @jseyfried
frewsxcv added a commit to frewsxcv/rust that referenced this issue Mar 25, 2017
Add warning for use of lifetime parameter with 'static bound

Previously a `'static` lifetime bound would result in an `undeclared lifetime` error when compiling, even though it could be considered valid.

However, it is unnecessary to use it as a lifetime bound so we present the user with a warning instead and suggest using the `'static` lifetime directly, in place of the lifetime parameter. We can change this to an error (or warning with lint) if that's decided to be more appropriate.

Example output:
```
warning: unnecessary lifetime parameter `'a`
 --> ../static-lifetime-bound.rs:3:10
  |
3 | fn f<'a: 'static>(val: &'a i32) {
  |      ^^^^^^^^^^^
  |
  = help: you can use the `'static` lifetime directly, in place `'a`
```

Fixes rust-lang#40661

r? @jseyfried
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 A-resolve Area: Name resolution E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion.
Projects
None yet
Development

No branches or pull requests

5 participants