Rust: Tracking issue for static lifetime in statics (RFC #1623)

[nikomatsakis]

Tracking issue for "static lifetime in statics", rust-lang/rfcs#1623, which defaults omitted lifetimes in statics to 'static.

cc @llogiq

[nikomatsakis]

I would be up for mentoring someone in implementing this (nmatsakis on IRC).

[llogiq]

Cool! I'm not sure if I can find the time, but if I do, I'd be glad to code this up.

[nikomatsakis]

Here are some pointers into the code:

• first off, for historical reasons, the code often calls lifetimes regions :)
• when a region is elided, that winds up being resolved in librustc_typeck by a RegionScope, defined in librustc_typeck/rscope.rs; in particular the anon_regions() method is called to figure out what to do
• currently statics use an ExplicitRscope; this is selected in this code in collect.rs, which handles statics and constants
• we would want to switch that to a ElidableRscope with default set to ty::ReStatic, I think

[llogiq]

Great! I think with those pointers I should be able to make _some_ progress even with a modest amount of time.

[nikomatsakis]

This should not have been closed.

[nikomatsakis]

(Until it becomes stable.)

[llogiq]

@chriskrycho just a friendly heads-up: Did you get around to documenting this?

[chriskrycho]

I did not, but it’s on my list for after-work tasks this week!

[nikomatsakis]

@llogiq this is fully implemented at this point, right? I guess we are blocked on some documentation efforts? I'd like to stabilize this change.

[chriskrycho]

This was, perhaps ironically given my RFC, blocked on me actually getting around to documenting it. I will aim to document it Monday.

[nikomatsakis]

@chriskrycho

This was, perhaps ironically given my RFC, blocked on me actually getting around to documenting it. I will aim to document it Monday.

OK :)

[llogiq]

I too would love to see this stabilized. Thank you Niko for pushing this forward! Also thank you Chris for caring about the docs.

[chriskrycho]

Sorry, didn’t get to this today as I was sick. Tomorrow, tomorrow, tomorrow!

[llogiq]

Get well soon!

[chriskrycho]

Documentation PR inbound shortly!

[aturon]

I'm going to go ahead and nominate for FCP, to kick the process off. Note that actual stabilization is blocked by docs landing, but we can at least start discussing whether to move to FCP (which itself lasts several weeks).

@rfcbot fcp merge

[llogiq]

As I commented on #37928, removing the feature gate would very probably make the doc tests pass, thus removing the last hurdle before merging.

It's a bit unfortunate to have this deadlock problem, but perhaps we can learn something from it?

[chriskrycho]

Yeah, this is a process thing I didn't see coming in the discussion in https://github.com/rust-lang/rfcs/issues/1636.

[rfcbot]

Team member @aturon has proposed to merge this. The next step is review by the rest of the tagged teams:

• [x] @aturon
• [x] @eddyb
• [x] @nikomatsakis
• [x] @nrc
• [x] @pnkfelix
• [x] @withoutboats

No concerns currently listed.

Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[withoutboats]

@rfcbot reviewed

[pnkfelix]

@rfcbot reviewed

[est31]

@rfcbot you are broken! Something is supposed to happen here, no?

[eddyb]

I've checked off both of them manually just now, maybe that will do something?

[nikomatsakis]

Hmm, cc @dikaiosune :( -- rfcbot doesn't seem to be noticing that we are ready to take action here

[aturon]

OK, I'm going to put this into FCP manually.

:bell: This feature is entering its final comment period for stabilization. :bell:

[nikomatsakis]

@rfcbot reviewed

[rfcbot]

:bell: This is now entering its final comment period, as per the review above. :bell:

psst @aturon, I wasn't able to add the final-comment-period label, please do so.

[rfcbot]

The final comment period is now complete.

[brson]

Reopening until this is backported to 1.16.

[nikomatsakis]

@brson wait, why are we backporting? We don't normally backport new features and stabilizations, do we? This seems relatively minor.

[alexcrichton]

@nikomatsakis would the lang team prefer to not backport? I don't think there's been a definitive answer in either https://github.com/rust-lang/rust/pull/39265 (stabilization PR) or in https://github.com/rust-lang/rust/pull/37928 (doc PR).

I believe @est31 proposed a backport and I tagged it as such b/c of the request, but no answer has been had.

If the answer is "no", however, then we can denominate and remove from milestones.

[est31]

Just note that back when I was proposing the backport, I thought that stabilisations usually do get backported. Didn't know that its usually only done exceptionally.

[llogiq]

Given that it's not much code, a backport wouldn't be that costly (and probably much appreciated :smile:).

But I'm also fine with waiting for 1.17 if there are more pressing matters.

[aturon]

@alexcrichton I think we should not backport. This is just a normal stabilization and should follow the normal process.

[alexcrichton]

Sounds like the backport isn't gonna happen, so I'm going to remove beta-nominated from the PRs and un-milestone this issue.

[alexcrichton]

Er, also re-close this issue

[golddranks]

@brson, this feature is still mentioned in release notes, even though it didn't land.