Repository navigation
Closed
Labels
B-RFC-approvedBlocker: Approved by a merged RFC but not yet implemented.Blocker: Approved by a merged RFC but not yet implemented.B-unstableBlocker: Implemented in the nightly compiler and unstable.Blocker: Implemented in the nightly compiler and unstable.C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCCategory: An issue tracking the progress of sth. like the implementation of an RFCE-easyCall for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.T-langRelevant to the language teamRelevant to the language teamfinal-comment-periodIn the final comment period and will be merged soon unless new substantive objections are raised.In the final comment period and will be merged soon unless new substantive objections are raised.
Description
RFC: https://github.com/rust-lang/rfcs/blob/master/text/1414-rvalue_static_promotion.md
RFC PR: rust-lang/rfcs#1414
Promote constexpr rvalues to values in static memory instead of stack slots, and expose those in the language by being able to directly create 'static references to them. This would allow code like let x: &'static u32 = &42 to work.
Related issues (closed in favor of this one):
- Lifetime of fn() converted to &Fn() isn't long enough #28546 -- contains an example test case!
Metadata
Metadata
Assignees
Labels
B-RFC-approvedBlocker: Approved by a merged RFC but not yet implemented.Blocker: Approved by a merged RFC but not yet implemented.B-unstableBlocker: Implemented in the nightly compiler and unstable.Blocker: Implemented in the nightly compiler and unstable.C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCCategory: An issue tracking the progress of sth. like the implementation of an RFCE-easyCall for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.T-langRelevant to the language teamRelevant to the language teamfinal-comment-periodIn the final comment period and will be merged soon unless new substantive objections are raised.In the final comment period and will be merged soon unless new substantive objections are raised.
Activity
eddyb commentedon Jan 6, 2017
If anyone is interested, all you have to do is remove this
& falseand write tests.meetmangukiya commentedon Jan 6, 2017
I'd like to take a shot at this
theduke commentedon Jan 10, 2017
Just removing the match statement mentioned by @eddyb results in errors in core, all (at least until abort) related to
& mut[]:Is there something going on with
[]being recognized as promotable to static?I'll start getting familiar with the code. 🔬
eddyb commentedon Jan 10, 2017
It's special-cased still in the RFC, it's the only mutable borrow that is promoted, and handling it at the same time as everything else didn't work out, so what you're seeing is entirely expected.
brson commentedon Feb 15, 2017
Is anybody working on this? Seems like any easy thing to push through. Seems like 1.19 is the earliest this could stablize if it makes it to 1.17 beta.
eddyb commentedon Feb 15, 2017
My assessment is still correct AFAIK, not sure what happened to @theduke.
badtuple commentedon Feb 19, 2017
Seems like a couple people started and then dropped this...but if no one is working on it still then I'll do it tonight when I get home.
eddyb commentedon Feb 19, 2017
FWIW, if you do want to feature-gate this, you'll have to put a condition in the place of
& false(as opposed to just removing it), but it should still be that same place you need to change.brson commentedon Feb 24, 2017
Go for it @badtuple !
topecongiro commentedon Mar 4, 2017
Hello. Is @badtuple still working on this? If not, I would like to take a shot at this.
Rollup merge of rust-lang#40441 - tschottdorf:promotable-rfc, r=eddyb
9 remaining items
Veedrac commentedon May 5, 2017
@eddyb I think you understand the suggestion correctly. I'm not following what you're saying the problem with copies is, though. Surely "
Code" is just an unsized, non-Copytype, so you can't copy it around without specifically-defined functions?eddyb commentedon May 5, 2017
@Veedrac I meant "copy" as in "the
memcpyrequired for moves", and if you only ever started with references, I suppose you can't end up there, IIRC @nikomatsakis thought the same.A similar point is made by proponents of using types like
&OpaqueDatain FFI, I suppose.I'd comment on #1037 and/or open a new issue/RFC about it if I were you - personally I don't see any problem with a coercion from
fn()(not any specificCode-like schemes).eddyb commentedon Jul 22, 2017
@rfcbot fcp merge
I propose that we stabilize this, as the feature gate has been implemented, the underlying promotion mechanism has been in the compiler for years and I can't think of any outstanding problem with it right now, and it makes #40036 implementable in a backwards-compatible manner.
rfcbot commentedon Jul 22, 2017
Team member @eddyb has proposed to merge this. The next step is review by the rest of the tagged teams:
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.
nikomatsakis commentedon Jul 23, 2017
@eddyb and I discussed a bit this statement of theirs:
and I just wanted to elaborate on what it means for future reference. In short, today, you get an error for something like this:
which yields:
As the error says, this is because the temporary for
&0gets freed after theletcompletes, but the binding will hold onto that reference until the end of the block. In a static context, however,Some(&0)is currently accepted:If we were to adopt the changes described in #40036, however, then this code would be in error again -- the max lifetime of
&0would be "local" to the const evaluation (it would be a value that gets dropped as part of constant evaluation, and hence we wouldn't be allowed to retain a reference to it in the final value). This would be a regression.Rvalue promotion resolves by accepting both variants: since
0is something we could rvalue promote, the max lifetime is'static, and the temporary created by&0is exempt from the normal lifetime limits.aturon commentedon Aug 2, 2017
(Checking the box for @pnkfelix, who is away)
rfcbot commentedon Aug 2, 2017
🔔 This is now entering its final comment period, as per the review above. 🔔
rfcbot commentedon Aug 12, 2017
The final comment period is now complete.
Auto merge of #43838 - eddyb:stable-rvalue-promotion, r=arielb1
isaacthefallenapple commentedon Jul 13, 2022
I just stumbled on this:
Is there a reason this doesn't/shouldn't work?