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.

Sign up for GitHub

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

Jump to bottom

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

Closed
nikomatsakis opened this issue Aug 22, 2016 · 37 comments
Closed

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

nikomatsakis opened this issue Aug 22, 2016 · 37 comments
Labels
B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. B-unstable Blocker: Implemented in the nightly compiler and unstable. E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. T-lang Relevant to the language team, which will review and decide on the PR/issue.

Comments

@nikomatsakis
Copy link
Contributor

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

cc @llogiq
@nikomatsakis nikomatsakis added B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. T-lang Relevant to the language team, which will review and decide on the PR/issue. B-unstable Blocker: Implemented in the nightly compiler and unstable. E-help-wanted Call for participation: Help is requested to fix this issue. E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. and removed E-help-wanted Call for participation: Help is requested to fix this issue. labels Aug 22, 2016
@nikomatsakis
Copy link
Contributor Author

nikomatsakis commented Aug 22, 2016 •
edited
Loading

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

@llogiq
Copy link
Contributor

llogiq commented Aug 22, 2016

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

@nikomatsakis
Copy link
Contributor Author

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
Copy link
Contributor

llogiq commented Aug 22, 2016

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

bors added a commit that referenced this issue Sep 2, 2016
@bors
Auto merge of #35915 - llogiq:rfc-1623, r=nikomatsakis
022cb6d 
implementing RFC 1623. This fixes #35897.

This is a work in progress. In particular, I want to add more tests,
especially the compile-fail test is very bare-bones.
@bors bors closed this as completed in cfce351 Sep 2, 2016
@nikomatsakis nikomatsakis reopened this Sep 2, 2016
@nikomatsakis
Copy link
Contributor Author

This should not have been closed.

@nikomatsakis
Copy link
Contributor Author

(Until it becomes stable.)

@nikomatsakis nikomatsakis mentioned this issue Sep 2, 2016
Closed
@llogiq
Copy link
Contributor

llogiq commented Sep 14, 2016

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

@chriskrycho
Copy link
Contributor

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

@nikomatsakis
Copy link
Contributor Author

@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
Copy link
Contributor

chriskrycho commented Nov 11, 2016 via email

@nikomatsakis
Copy link
Contributor Author

@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
Copy link
Contributor

llogiq commented Nov 14, 2016

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
Copy link
Contributor

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

@llogiq
Copy link
Contributor

llogiq commented Nov 15, 2016

Get well soon!

@chriskrycho
Copy link
Contributor

Documentation PR inbound shortly!

@chriskrycho chriskrycho mentioned this issue Nov 22, 2016
Merged
@aturon
Copy link
Member

aturon commented Dec 14, 2016

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
Copy link
Contributor

llogiq commented Dec 14, 2016

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
Copy link
Contributor

Yeah, this is a process thing I didn't see coming in the discussion in rust-lang/rfcs#1636.

@nikomatsakis
Copy link
Contributor Author

@rfcbot reviewed

@rfcbot
Copy link

rfcbot commented Jan 23, 2017

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

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

@est31 est31 mentioned this issue Jan 23, 2017
Merged
2 tasks
@rfcbot
Copy link

rfcbot commented Feb 2, 2017

The final comment period is now complete.

est31 added a commit to est31/rust that referenced this issue Feb 8, 2017
@est31
Stabilize static in const
f8b6108 
Closes rust-lang#35897.
frewsxcv added a commit to frewsxcv/rust that referenced this issue Feb 9, 2017
@frewsxcv
Rollup merge of rust-lang#37928 - chriskrycho:document-rfc-1623, r=st…
cc455b3 
…eveklabnik

Document RFC 1623: static lifetime elision.

This should be the last item required for stabilizing RFC 1623 (rust-lang#35897).
frewsxcv added a commit to frewsxcv/rust that referenced this issue Feb 9, 2017
@frewsxcv
Rollup merge of rust-lang#37928 - chriskrycho:document-rfc-1623, r=st…
7f7dc76 
…eveklabnik

Document RFC 1623: static lifetime elision.

This should be the last item required for stabilizing RFC 1623 (rust-lang#35897).
bors added a commit that referenced this issue Feb 9, 2017
@bors
Auto merge of #39265 - est31:master, r=petrochenkov
1129ce5 
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.
@brson
Copy link
Contributor

brson commented Feb 15, 2017

Reopening until this is backported to 1.16.

@brson brson reopened this Feb 15, 2017
@brson brson added this to the 1.16.0 milestone Feb 15, 2017
@nikomatsakis
Copy link
Contributor Author

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

@alexcrichton
Copy link
Member

@nikomatsakis would the lang team prefer to not backport? I don't think there's been a definitive answer in either #39265 (stabilization PR) or in #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
Copy link
Member

est31 commented Feb 17, 2017

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
Copy link
Contributor

llogiq commented Feb 17, 2017

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

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

@aturon
Copy link
Member

aturon commented Feb 21, 2017

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

@alexcrichton
Copy link
Member

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 alexcrichton removed this from the 1.16.0 milestone Feb 21, 2017
@alexcrichton
Copy link
Member

Er, also re-close this issue

@golddranks golddranks mentioned this issue Mar 10, 2017
Merged
@golddranks
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. B-unstable Blocker: Implemented in the nightly compiler and unstable. E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests