-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Elision in method can take 'static
from self
, perhaps surprising
#48686
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
Comments
Sounds like a case of "disallow elided lifetimes that refer to explicit lifetimes", I recall @nikomatsakis being in favor of forbidding this. |
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. |
'static
from self
, perhaps surprising
I retitled the issue to be less dramatic =) |
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. |
@rustbot claim |
…gillot Lint that warns when an elided lifetime ends up being a named lifetime As suggested in rust-lang#48686 (comment) Fixes rust-lang#48686 ## TODO: - [ ] Crater run? ## Questions: - [ ] Should we separate the `'static` case and the named lifetime parameter case? - [ ] Should this be `Allow` or `Warn` by default? - [ ] Should this be gated behind an edition? ## Future improvemetns: - [ ] Add machine-applicable suggestions `@rustbot` label A-lint
Rollup merge of rust-lang#129207 - GrigorenkoPV:elided-is-named, r=cjgillot Lint that warns when an elided lifetime ends up being a named lifetime As suggested in rust-lang#48686 (comment) Fixes rust-lang#48686
Lint that warns when an elided lifetime ends up being a named lifetime As suggested in rust-lang/rust#48686 (comment) Fixes #48686
Lint that warns when an elided lifetime ends up being a named lifetime As suggested in rust-lang/rust#48686 (comment) Fixes #48686
Lint that warns when an elided lifetime ends up being a named lifetime As suggested in rust-lang/rust#48686 (comment) Fixes #48686
… r=<try> Add a new `mismatched-lifetime-syntaxes` lint The lang-team [discussed this](https://hackmd.io/nf4ZUYd7Rp6rq-1svJZSaQ) and I attempted to [summarize](#120808 (comment)) their decision. The summary-of-the-summary is: - Using two different kinds of syntax for elided lifetimes is confusing. In rare cases, it may even [lead to unsound code](#48686)! Some examples: ```rust // Lint will warn about these fn(v: ContainsLifetime) -> ContainsLifetime<'_>; fn(&'static u8) -> &u8; ``` - Matching up references with no lifetime syntax, references with anonymous lifetime syntax, and paths with anonymous lifetime syntax is an exception to the simplest possible rule: ```rust // Lint will not warn about these fn(&u8) -> &'_ u8; fn(&'_ u8) -> &u8; fn(&u8) -> ContainsLifetime<'_>; ``` - Having a lint for consistent syntax of elided lifetimes will make the [future goal](#91639) of warning-by-default for paths participating in elision much simpler. --- This new lint attempts to accomplish the goal of enforcing consistent syntax. In the process, it supersedes and replaces the existing `elided-named-lifetimes` lint, which means it starts out life as warn-by-default.
… r=<try> Add a new `mismatched-lifetime-syntaxes` lint The lang-team [discussed this](https://hackmd.io/nf4ZUYd7Rp6rq-1svJZSaQ) and I attempted to [summarize](#120808 (comment)) their decision. The summary-of-the-summary is: - Using two different kinds of syntax for elided lifetimes is confusing. In rare cases, it may even [lead to unsound code](#48686)! Some examples: ```rust // Lint will warn about these fn(v: ContainsLifetime) -> ContainsLifetime<'_>; fn(&'static u8) -> &u8; ``` - Matching up references with no lifetime syntax, references with anonymous lifetime syntax, and paths with anonymous lifetime syntax is an exception to the simplest possible rule: ```rust // Lint will not warn about these fn(&u8) -> &'_ u8; fn(&'_ u8) -> &u8; fn(&u8) -> ContainsLifetime<'_>; ``` - Having a lint for consistent syntax of elided lifetimes will make the [future goal](#91639) of warning-by-default for paths participating in elision much simpler. --- This new lint attempts to accomplish the goal of enforcing consistent syntax. In the process, it supersedes and replaces the existing `elided-named-lifetimes` lint, which means it starts out life as warn-by-default.
… r=<try> Add a new `mismatched-lifetime-syntaxes` lint The lang-team [discussed this](https://hackmd.io/nf4ZUYd7Rp6rq-1svJZSaQ) and I attempted to [summarize](#120808 (comment)) their decision. The summary-of-the-summary is: - Using two different kinds of syntax for elided lifetimes is confusing. In rare cases, it may even [lead to unsound code](#48686)! Some examples: ```rust // Lint will warn about these fn(v: ContainsLifetime) -> ContainsLifetime<'_>; fn(&'static u8) -> &u8; ``` - Matching up references with no lifetime syntax, references with anonymous lifetime syntax, and paths with anonymous lifetime syntax is an exception to the simplest possible rule: ```rust // Lint will not warn about these fn(&u8) -> &'_ u8; fn(&'_ u8) -> &u8; fn(&u8) -> ContainsLifetime<'_>; ``` - Having a lint for consistent syntax of elided lifetimes will make the [future goal](#91639) of warning-by-default for paths participating in elision much simpler. --- This new lint attempts to accomplish the goal of enforcing consistent syntax. In the process, it supersedes and replaces the existing `elided-named-lifetimes` lint, which means it starts out life as warn-by-default.
Uh oh!
There was an error while loading. Please reload this page.
rustc currently compiles the following with no warnings or errors:
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 isfn get_mut(&'static self, x: &mut u8) -> &'static mut u8
.The following code produces an error:
This seems like it could be fixed by disallowing elision in this case via a lint.
cc @aturon
The text was updated successfully, but these errors were encountered: