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

Elision in method can take 'static from self, perhaps surprising #48686

Open
cramertj opened this issue Mar 2, 2018 · 4 comments
Open

Elision in method can take 'static from self, perhaps surprising #48686

cramertj opened this issue Mar 2, 2018 · 4 comments
Labels
A-lifetimes Area: lifetime related A-lint Area: Lints (warnings about flaws in source code) such as unused_mut. C-enhancement Category: An issue proposing an enhancement or a PR with one. E-help-wanted Call for participation: Help is requested to fix this issue. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@cramertj
Copy link
Member

cramertj commented Mar 2, 2018

rustc currently compiles the following with no warnings or errors:

struct Foo;

impl Foo {
    pub fn get_mut(&'static self, x: &mut u8) -> &mut u8 {
        unsafe { &mut *(x as *mut _) }
    }
}

However, attempting to make this function safe reveals that the elided lifetime of x isn't the lifetime in the return type-- it's instead copying over the 'static lifetime into the return type! Rustdoc actually documents that the signature of this method is fn get_mut(&'static self, x: &mut u8) -> &'static mut u8.

The following code produces an error:

struct Foo;

impl Foo {
    pub fn get_mut(&'static self, x: &mut u8) -> &mut u8 {
        x
    }
}
error[E0312]: lifetime of reference outlives lifetime of borrowed content...
 --> src/main.rs:7:9
  |
7 |         x
  |         ^
  |
  = note: ...the reference is valid for the static lifetime...
note: ...but the borrowed content is only valid for the anonymous lifetime #1 defined on the method body at 6:5
 --> src/main.rs:6:5
  |
6 | /     pub fn get_mut(&'static self, x: &mut u8) -> &mut u8 {
7 | |         x
8 | |     }
  | |_____^

error: aborting due to previous error

error: Could not compile `playground`.

This seems like it could be fixed by disallowing elision in this case via a lint.

cc @aturon

@leoyvens
Copy link
Contributor

leoyvens commented Mar 2, 2018

Sounds like a case of "disallow elided lifetimes that refer to explicit lifetimes", I recall @nikomatsakis being in favor of forbidding this.

@nikomatsakis
Copy link
Contributor

I agree this is undesirable, but as @leodasvacas notes, I would say 'no more undesirable than any other named lifetime'. We should implement that lint.

@nikomatsakis nikomatsakis changed the title Invalid elision in methods Elision in method can take 'static from self, perhaps surprising Mar 6, 2018
@nikomatsakis
Copy link
Contributor

I retitled the issue to be less dramatic =)

@pietroalbini pietroalbini added C-bug Category: This is a bug. A-lifetimes Area: lifetime related T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Mar 6, 2018
@Enselic
Copy link
Member

Enselic commented Nov 18, 2023

Triage: Marking as E-help-wanted to implement a lint that warns when an elided lifetime ends up being a named lifetime. There seems to be a broad consensus that this would be good to lint for.

@Enselic Enselic added C-enhancement Category: An issue proposing an enhancement or a PR with one. A-lint Area: Lints (warnings about flaws in source code) such as unused_mut. E-help-wanted Call for participation: Help is requested to fix this issue. and removed C-bug Category: This is a bug. labels Nov 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-lifetimes Area: lifetime related A-lint Area: Lints (warnings about flaws in source code) such as unused_mut. C-enhancement Category: An issue proposing an enhancement or a PR with one. E-help-wanted Call for participation: Help is requested to fix this issue. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

5 participants