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

elided_lifetimes_in_paths lint is broken #51902

Closed
reuvenpo opened this issue Jun 29, 2018 · 4 comments
Closed

elided_lifetimes_in_paths lint is broken #51902

reuvenpo opened this issue Jun 29, 2018 · 4 comments
Labels
A-lifetimes Area: lifetime related A-lint Area: Lints (warnings about flaws in source code) such as unused_mut.

Comments

@reuvenpo
Copy link

reuvenpo commented Jun 29, 2018

Using the latest stable compiler(1.27) (and probably earlier ones too) given the snippet:

#![deny(elided_lifetimes_in_paths)]

struct Bar<'a> {
    a: &'a i32,
}

fn main() {
    let bar = Bar::<'_> {a: &42};
}

we get the error:

error: hidden lifetime parameters are deprecated, try `Foo<'_>`
 --> src/main.rs:8:21
  |
8 |     let bar = Bar::<'_> {a: &42};
  |                     ^^
  |
note: lint level defined here
 --> src/main.rs:1:9
  |
1 | #![deny(elided_lifetimes_in_paths)]
  |         ^^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to previous error

This makes no sense, both because the name Foo is constant in the error message, and both because the lifetime parameter suggested doesn't fix anything. (again, because the error message is just a constant)
https://doc.rust-lang.org/nightly/nightly-rustc/rustc/lint/builtin/static.ELIDED_LIFETIMES_IN_PATHS.html

Note, this does compile:

#![deny(elided_lifetimes_in_paths)]

struct Bar<'a> {
    a: &'a i32,
}

fn fun<'a>() {
    let bar = Bar::<'a> {a: &42};
}

fn main() {
    fun();
}

but since main can't have any lifetime parameters, Bar can no be initialized directly in main, and fun is defined with a lifetime parameter that is only used internally, rather than giving any information about how the function is to be used.

while experimenting with the same code, THIS COMPILED:

// #![deny(elided_lifetimes_in_paths)]  // Note this is commented out, as in, unrelated

struct Foo {
    a: i32
}

struct Bar<'a> {
    a: &'a Foo,
}

fn fun<'a>() -> Bar<'a> {
    let bar = Bar::<'a> {a: &Foo{a: 42}};
    bar
}

fn main() {
    fun();
}

EDIT: This last example compiles because of the "rvalue static promotion" feature, which i was not aware of when opening the issue. Had that Foo been a mutable local variable, this would correctly fail. Learn something new every day :)

See also #51903.

@stokhos stokhos added A-lint Area: Lints (warnings about flaws in source code) such as unused_mut. A-lifetimes Area: lifetime related labels Jun 29, 2018
@zackmdavis
Copy link
Member

The elided-lifetimes-in-paths lint was rewritten in #52069; the example code in this issue no longer warns.

zmd@ReflectiveCoherence:~/Code/Misc$ cat 51902.rs 
#![allow(unused)]
#![deny(elided_lifetimes_in_paths)]

struct Bar<'a> {
    a: &'a i32,
}

fn main() {
    let bar = Bar::<'_> {a: &42};
}
zmd@ReflectiveCoherence:~/Code/Misc$ rustc +nightly 51902.rs 
zmd@ReflectiveCoherence:~/Code/Misc$ echo $?
0

@reuvenpo
Copy link
Author

Awesome :)
This would solve the first part of this issue.
As far as i understand the second part is still an open question though.

(And, of course, the third one is no issue at all :) )

@zackmdavis
Copy link
Member

As far as i understand the second part is still an open question though.

Can you be more explicit? I assume "the second part" refers to the part of the issue starting with "Note, this does compile", but I don't understand what you're suggesting the compiler should do differently. I'm going to close this to keep the issue-tracker tidy, but please re-open or file a new issue if you still have concerns with the elided_lifetimes_in_paths lint (or anything else).

@reuvenpo
Copy link
Author

Oh, you know what @zackmdavis, I'm not sure what I was thinking when I wrote my previous comment, but if the snippet you sent compiles, then the same trick (using Bar::<'_> { a: &42 }) should work to make my seconds example look nicer (basically, not having to specify a generic type parameter in a function signature that does not apply to any of its parameters or return value).

Thanks for the help :)

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.
Projects
None yet
Development

No branches or pull requests

3 participants