-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Document RFC 1623: static lifetime elision. #37928
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @steveklabnik (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
src/doc/reference.md
Outdated
address will have the `static` lifetime. The compiler is, however, still at | ||
liberty to translate the constant many times, so the address referred to may not | ||
be stable. | ||
address will have the `static` lifetime. (See below on [static lifetime elision](#static-lifetime-elision).) The compiler is, however, still at liberty to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you wrap this line to match the indentation of the surrounding lines?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agh, yes. I've updated it; I meant to fix that before I pushed it!
So, @rust-lang/docs , this raises a question. How do we make the distinction between stable and unstable stuff here? |
I think at some point, we are going to need to build infrastructure for versioning. That is going to be some work, but I do not see how we can handle these kinds of cases long-term without it. I can open an issue to that effect if you like. And maybe ping some of the Ember people who worked on their infrastructure that way.
|
It should have an unstable version. I don't have much better idea. :-/ |
I just noted that all the code samples in reference.md get tested. Neat! I'll update the sample accordingly in the morning. |
I don't have any great ideas either, other than explicitly mentioning that it's unstable in the paragraph above and adding in the |
Putting this on this week's doc team agenda. |
We could change the feature implementation to my first commit, thus stabilizing the feature and removing the extra code adding the feature gate that makes it unstable in the first place. I presume this should make the doc tests pass. |
So, we talked about this at the docs meeting today. What it really boils down to is this: it'd be a shame to block this based on figuring out the broader story here. However, once we know that the rest of the feature will be stable, we can just land this, then land the stabilization of the feature. @aturon just put the feature into FCP, so let's see how that goes before we merge. And in the meantime, let's figure out the broader docs story. I'm going to open an issue on the RFCs repo about this. |
Related: I'll have time Friday or Saturday to update the not-the-feature-gate bits of the test that are broken here—there's one piece that needs to be tweaked independent of the stabilization/feature flag issue. |
Kept spacing this; came back to it via other issues. I'll update the non-feature-gate related parts tonight or tomorrow! |
@chriskrycho do you need any help? |
@llogiq gah. Slipped my mind. The only thing that needs tweaking is setting |
I just pushed a fixed version of the commit which just includes all the required pieces. We'll see what Travis says… |
UGH. I pushed the rebase, but not the fix. This is how my whole first day back at work has been. 🤦♂️ |
@chriskrycho travis is still failing: https://travis-ci.org/rust-lang/rust/jobs/188704796#L1662 |
🤔 Grr. I will follow up Wednesday evening. Family commitments till then.
|
No worries! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually this is full elision with a 'static
default. This means that if the types contains fn
s, the usual elision rules will apply, only choosing 'static
if no elision rule applies.
@llogiq can you elaborate? @steveklabnik I seem to have failed in pacifying Travis and the feature gate. Can you take a gander and indicate what I did wrong? |
This means if you have a |
I think you can fix it by adding |
src/doc/reference.md
Outdated
without the lifetimes. Returning to our previous example: | ||
|
||
```rust | ||
#[feature(static_in_const)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this should be #![feature(static_in_const)]
; you forgot the exclamation point.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
YOU ARE MY HERO
I think I could improve it, but I need to find the time first. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also after the example, add a paragraph to explain the elision:
In case the static or constant items contain function references or closures, and those work with references, the compiler will try the usual elision rules (link to elision). Failing that, it will default the lifetimes to 'static
. This is best explained by an example:
const FUN : fn(&str) -> &str = ..
// per rule #1, this is fn<'a>(&'a str) -> &'a str
const FUNNY : Fn(&Foo, &Bar, &Baz) -> usize = ..
// per rule #2, this is Fn<'a, 'b, 'c>(&'a Foo, &'b Bar, &'c Baz) -> usize
const UNFUNNY : Fn(&Foo, &Bar) -> &Baz = ..
// neither rule applies, so all `&`s are `'static`
src/doc/reference.md
Outdated
@@ -1271,15 +1271,16 @@ guaranteed to refer to the same memory address. | |||
|
|||
Constant values must not have destructors, and otherwise permit most forms of | |||
data. Constants may refer to the address of other constants, in which case the | |||
address will have the `static` lifetime. The compiler is, however, still at | |||
address will have the `static` lifetime. (See below on [static lifetime |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about "will have elided lifetimes where applicable, otherwise – in most cases – defaulting to the 'static
lifetime.
Now that beta branched, I would like to ask for beta backport nomination, so that already 1.16 would have it stabilized. |
Good idea. |
@chriskrycho ping! any interest in keeping this going? this is still blocking stabilization. @est31 I would be strongly against this; stabilization backports are incredibly rare. |
@steveklabnik yeah, should be able to allocate an hour to it tomorrow. I'll pull in @llogiq's comments, as well as fix the build issue, then. |
We may also want to show embedded lifetimes, e.g. |
@llogiq regarding your last comment: did that change with this RFC/implementation? If not, I'd prefer to note it as something to add in a separate commit/PR. I think we actually need a dedicated section for lifetime elision in general; right now it appears to be documented in detail only in the nomicon. |
Updated with everything other than the embedded lifetimes scenario, and it passed |
Travis passed! @bors: r+ rollup thanks a ton @chriskrycho |
📌 Commit 4096dd6 has been approved by |
YESSSSSSSSSSS. FINALLLYYYYYYYY. Sorry for the many delays on this, everyone! Glad it's finally in. So it'll land in, what, 1.17? |
…eveklabnik Document RFC 1623: static lifetime elision. This should be the last item required for stabilizing RFC 1623 (rust-lang#35897).
yes. |
…eveklabnik Document RFC 1623: static lifetime elision. This should be the last item required for stabilizing RFC 1623 (rust-lang#35897).
Stabilize static lifetime in statics Stabilize the "static_in_const" feature. Blockers before this PR can be merged: * [x] The [FCP with inclination to stabilize](#35897 (comment)) needs to be over. FCP lasts roughly three weeks, so will be over at Jan 25, aka this thursday. * [x] Documentation needs to be added (#37928) Closes #35897.
Removing beta nomination as sentiment seems to be to not backport (also see #35897) |
This should be the last item required for stabilizing RFC 1623 (#35897).