-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Tracking Issue for #![feature(const_cell_into_inner)]
#78729
Comments
…lnay Constantify `UnsafeCell::into_inner` and related Tracking issue: rust-lang#78729 This PR constantifies: - `UnsafeCell::into_inner` - `Cell::into_inner` - `RefCell::into_inner` - `Atomic*::into_inner` r? `@dtolnay`
…lnay Constantify `UnsafeCell::into_inner` and related Tracking issue: rust-lang#78729 This PR constantifies: - `UnsafeCell::into_inner` - `Cell::into_inner` - `RefCell::into_inner` - `Atomic*::into_inner` r? ``@dtolnay``
…lnay Constantify `UnsafeCell::into_inner` and related Tracking issue: rust-lang#78729 This PR constantifies: - `UnsafeCell::into_inner` - `Cell::into_inner` - `RefCell::into_inner` - `Atomic*::into_inner` r? ```@dtolnay```
…lnay Constantify `UnsafeCell::into_inner` and related Tracking issue: rust-lang#78729 This PR constantifies: - `UnsafeCell::into_inner` - `Cell::into_inner` - `RefCell::into_inner` - `Atomic*::into_inner` r? ````@dtolnay````
…lnay Constantify `UnsafeCell::into_inner` and related Tracking issue: rust-lang#78729 This PR constantifies: - `UnsafeCell::into_inner` - `Cell::into_inner` - `RefCell::into_inner` - `Atomic*::into_inner` r? `````@dtolnay`````
@rfcbot merge cc @rust-lang/wg-const-eval |
Team member @m-ou-se has proposed to merge this. The next step is review by the rest of the tagged team members: No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), 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. |
🔔 This is now entering its final comment period, as per the review above. 🔔 |
The final comment period, with a disposition to merge, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon. |
According to #84087 (comment), this is blocked on the "precise drop analysis" unstable const feature (#73255). |
…lstrieb Stabilize const Atomic*::into_inner Partial stabilization for rust-lang#78729, for which the FCP has already completed. The other `into_inner` functions in that tracking issue (`UnsafeCell`, `Cell`, `RefCell`) are blocked on rust-lang#73255 for now. ```console error[E0493]: destructor of `UnsafeCell<T>` cannot be evaluated at compile-time --> library/core/src/cell.rs:2076:29 | 2076 | pub const fn into_inner(self) -> T { | ^^^^ the destructor for this type cannot be evaluated in constant functions 2077 | self.value 2078 | } | - value is dropped here ```
Rollup merge of rust-lang#123522 - dtolnay:constatomicintoinner, r=Nilstrieb Stabilize const Atomic*::into_inner Partial stabilization for rust-lang#78729, for which the FCP has already completed. The other `into_inner` functions in that tracking issue (`UnsafeCell`, `Cell`, `RefCell`) are blocked on rust-lang#73255 for now. ```console error[E0493]: destructor of `UnsafeCell<T>` cannot be evaluated at compile-time --> library/core/src/cell.rs:2076:29 | 2076 | pub const fn into_inner(self) -> T { | ^^^^ the destructor for this type cannot be evaluated in constant functions 2077 | self.value 2078 | } | - value is dropped here ```
`Cell` and `RefCell` have their `into_inner` methods const unstable. `OnceCell` has the same logic, so add it under the same gate. Tracking issue: rust-lang#78729
Since this is still blocked, I made |
…r, r=Noratrieb Add `const_cell_into_inner` to `OnceCell` `Cell` and `RefCell` have their `into_inner` methods const unstable. `OnceCell` has the same logic, so add it under the same gate. Tracking issue: rust-lang#78729
…r, r=Noratrieb Add `const_cell_into_inner` to `OnceCell` `Cell` and `RefCell` have their `into_inner` methods const unstable. `OnceCell` has the same logic, so add it under the same gate. Tracking issue: rust-lang#78729
Rollup merge of rust-lang#129382 - tgross35:once-cell-const-into-inner, r=Noratrieb Add `const_cell_into_inner` to `OnceCell` `Cell` and `RefCell` have their `into_inner` methods const unstable. `OnceCell` has the same logic, so add it under the same gate. Tracking issue: rust-lang#78729
…dtolnay stabilize const_cell_into_inner This const-stabilizes - `UnsafeCell::into_inner` - `Cell::into_inner` - `RefCell::into_inner` - `OnceCell::into_inner` `@rust-lang/wg-const-eval` this uses `rustc_allow_const_fn_unstable(const_precise_live_drops)`, so we'd be comitting to always finding *some* way to accept this code. IMO that's fine -- what these functions do is to move out the only field of a struct, and that struct has no destructor itself. The field's destructor does not get run as it gets returned to the caller. `@rust-lang/libs-api` this was FCP'd already [years ago](rust-lang#78729 (comment)), except that `OnceCell::into_inner` was added to the same feature gate since then (Cc `@tgross35).` Does that mean we have to re-run the FCP? If yes, I'd honestly prefer to move `OnceCell` into its own feature gate to not risk missing the next release. (That's why it's not great to add new functions to an already FCP'd feature gate.) OTOH if this needs an FCP either way since the previous FCP was so long ago, then we might as well do it all at once.
Rollup merge of rust-lang#130972 - RalfJung:const_cell_into_inner, r=dtolnay stabilize const_cell_into_inner This const-stabilizes - `UnsafeCell::into_inner` - `Cell::into_inner` - `RefCell::into_inner` - `OnceCell::into_inner` `@rust-lang/wg-const-eval` this uses `rustc_allow_const_fn_unstable(const_precise_live_drops)`, so we'd be comitting to always finding *some* way to accept this code. IMO that's fine -- what these functions do is to move out the only field of a struct, and that struct has no destructor itself. The field's destructor does not get run as it gets returned to the caller. `@rust-lang/libs-api` this was FCP'd already [years ago](rust-lang#78729 (comment)), except that `OnceCell::into_inner` was added to the same feature gate since then (Cc `@tgross35).` Does that mean we have to re-run the FCP? If yes, I'd honestly prefer to move `OnceCell` into its own feature gate to not risk missing the next release. (That's why it's not great to add new functions to an already FCP'd feature gate.) OTOH if this needs an FCP either way since the previous FCP was so long ago, then we might as well do it all at once.
This is a tracking issue for
#![feature(const_cell_into_inner)]
.Constantified functions are:
UnsafeCell::into_inner
Cell::into_inner
RefCell::into_inner
OnceCell::into_inner
(done)Atomic*::into_inner
Steps
UnsafeCell::into_inner
and related #78728, Addconst_cell_into_inner
toOnceCell
#129382)The text was updated successfully, but these errors were encountered: